Fehler bei BTC-Kontraktaufträgen: erst den Positionsmodus prüfen, nicht gleich erneut versuchen.
Wenn du das Skript zur Verwaltung des Kontrakts $BTC verwendest, sind Kauf-/Verkaufsrichtung und Positionsrichtung zwei verschiedene Dinge. In der aktuellen Binance-Dokumentation zu U-gebundenen (U本位) Kontrakten steht: Im Einwegmodus ist positionSide standardmäßig BOTH; im Zweiswegmodus muss LONG oder SHORT angegeben werden, und es darf kein reduceOnly-Parameter gesendet werden—false auch nicht ausgenommen.
Die Prüfung kannst du in dieser Reihenfolge machen: zuerst den aktuellen Positionsmodus des Kontos ansehen, dann side, positionSide und reduceOnly im Request abgleichen, und zuletzt die Order-Rückmeldung mit der tatsächlichen Position prüfen. Lösche den Schutzparameter nicht nur, um den Fehler zu beseitigen, und sende dann erneut—nur weil der Request durchgeht, bedeutet das nicht, dass er weiterhin dem ursprünglichen Zweck zum Reduzieren der Position entspricht.
Noch ein Unterschied: Die klare Ablehnung durch Parameter ist etwas anderes als ein Netzwerk-Timeout. Bei einem Timeout zuerst in der Auftragsaufzeichnung prüfen, ob die Order bereits akzeptiert wurde, und dann über das nächste Vorgehen entscheiden, um doppelte Beauftragungen zu vermeiden.
Hier werden nur die Regeln für Parameter zerlegt, keine Bestellanweisung gegeben; der Kontrakt bleibt mit Hebelwirkung und Ausführungsrisiken verbunden. Nutzt du aktuell Einweg- oder Zweisweg-Positionshaltung?
#合约教程 #Risikomanagement
Wenn du das Skript zur Verwaltung des Kontrakts $BTC verwendest, sind Kauf-/Verkaufsrichtung und Positionsrichtung zwei verschiedene Dinge. In der aktuellen Binance-Dokumentation zu U-gebundenen (U本位) Kontrakten steht: Im Einwegmodus ist positionSide standardmäßig BOTH; im Zweiswegmodus muss LONG oder SHORT angegeben werden, und es darf kein reduceOnly-Parameter gesendet werden—false auch nicht ausgenommen.
Die Prüfung kannst du in dieser Reihenfolge machen: zuerst den aktuellen Positionsmodus des Kontos ansehen, dann side, positionSide und reduceOnly im Request abgleichen, und zuletzt die Order-Rückmeldung mit der tatsächlichen Position prüfen. Lösche den Schutzparameter nicht nur, um den Fehler zu beseitigen, und sende dann erneut—nur weil der Request durchgeht, bedeutet das nicht, dass er weiterhin dem ursprünglichen Zweck zum Reduzieren der Position entspricht.
Noch ein Unterschied: Die klare Ablehnung durch Parameter ist etwas anderes als ein Netzwerk-Timeout. Bei einem Timeout zuerst in der Auftragsaufzeichnung prüfen, ob die Order bereits akzeptiert wurde, und dann über das nächste Vorgehen entscheiden, um doppelte Beauftragungen zu vermeiden.
Hier werden nur die Regeln für Parameter zerlegt, keine Bestellanweisung gegeben; der Kontrakt bleibt mit Hebelwirkung und Ausführungsrisiken verbunden. Nutzt du aktuell Einweg- oder Zweisweg-Positionshaltung?
#合约教程 #Risikomanagement