Erro em ordens de contrato de BTC—confira primeiro o modo de posição, não tente novamente com pressa.
Ao gerenciar contratos $BTC via script, a direção de compra/venda e o sentido de posição são coisas diferentes. A documentação atual da Binance para contratos U diz claramente: no modo unidirecional, o positionSide padrão é BOTH; no modo bidirecional, é obrigatório especificar LONG ou SHORT, e não é permitido enviar o parâmetro reduceOnly — mesmo preenchendo como false.
A verificação pode ser feita nesta ordem: primeiro veja o modo de posição atual da conta; depois confira o side, positionSide e reduceOnly na requisição; por fim, verifique a devolutiva da ordem versus a posição real. Não remova parâmetros de proteção apenas para eliminar o erro e reenviar; o fato de a requisição passar não significa que ela continue atendendo ao objetivo original de redução.
Há também uma diferença: rejeição explícita de parâmetros não é a mesma coisa que timeout de rede. Se houver timeout, primeiro confirme nos registros da ordem se ela já foi aceita e só então decida o próximo passo, para evitar delegações repetidas.
Aqui apenas destrinchamos regras de parâmetros; não fornecemos instruções para envio de ordens. O contrato ainda envolve risco de alavancagem e execução. Você está usando posição unidirecional ou bidirecional agora?
#合约教程 #Gerenciamento de risco
Ao gerenciar contratos $BTC via script, a direção de compra/venda e o sentido de posição são coisas diferentes. A documentação atual da Binance para contratos U diz claramente: no modo unidirecional, o positionSide padrão é BOTH; no modo bidirecional, é obrigatório especificar LONG ou SHORT, e não é permitido enviar o parâmetro reduceOnly — mesmo preenchendo como false.
A verificação pode ser feita nesta ordem: primeiro veja o modo de posição atual da conta; depois confira o side, positionSide e reduceOnly na requisição; por fim, verifique a devolutiva da ordem versus a posição real. Não remova parâmetros de proteção apenas para eliminar o erro e reenviar; o fato de a requisição passar não significa que ela continue atendendo ao objetivo original de redução.
Há também uma diferença: rejeição explícita de parâmetros não é a mesma coisa que timeout de rede. Se houver timeout, primeiro confirme nos registros da ordem se ela já foi aceita e só então decida o próximo passo, para evitar delegações repetidas.
Aqui apenas destrinchamos regras de parâmetros; não fornecemos instruções para envio de ordens. O contrato ainda envolve risco de alavancagem e execução. Você está usando posição unidirecional ou bidirecional agora?
#合约教程 #Gerenciamento de risco