后台“重发回调”允许对子订单重发，空 notify_url 会进入无效重试

[jiamovo]

当前子订单创建时会把 notify_url 置空，并把 callback_confirm 设为 Ok，目的是明确“不对子订单单独回调”。但后台“重发回调”接口没有排除这种子订单。

相关代码：

• src/model/service/order_service.go:413-430
• src/model/data/order_admin_data.go:118-128
• src/model/data/order_data.go:95-108
• src/mq/worker.go:168-185

当前行为：

• 子订单创建时 NotifyUrl 被写成空字符串
• ReopenOrderCallback() 只检查 status = pay_success，没有检查这条订单是否本来就不该回调
• 被重开后的订单会重新进入 GetPendingCallbackOrders()
• worker 取到后仍会走 sendOrderCallback()，最终对空 notify_url 发起无意义失败流程

影响：

• 管理员如果在后台对已支付子订单点击“重发回调”，会触发一轮无效重试
• 日志里会出现失败噪音，callback_num 也会被递增
• 对运维来说，这类订单本来就不该进入 resend callback 范围，现在界面和后端行为不一致

建议：

• “重发回调”前先过滤掉 notify_url 为空的订单，或至少排除子订单
• 更稳妥的做法是把“是否允许重发回调”做成显式条件，而不是只按 status = pay_success 判断

[jiamovo]

补充确认一下，v0.9.1 这里仍然是“前端规避，后端未收口”。

• 管理端订单页现在只在“已支付且 notify_url 非空”时显示“重发回调”按钮，这属于前端显示层规避。
• 但后端 /admin/api/v1/orders/{trade_id}/resend-callback 对应的 ReopenOrderCallback() 仍然只按 status = pay_success 判断，没有校验 notify_url 是否为空、是否为子订单、是否本来允许重发回调。

也就是说，只要直接调用后台接口，或后续前端条件变动，子订单仍然可以被重开 callback，随后重新进入 callback worker，对空 notify_url 继续走无意义重试。

所以这里目前更准确的状态应当是：前端已做临时规避，但后端接口仍缺少硬性校验，问题本身没有真正关闭。

建议后端至少补一层明确条件，例如：

• notify_url != ''
• 排除 parent_trade_id != '' 的子订单
• 或统一抽成“是否允许重发回调”的显式判断