审批流里很多“数据脏了”的问题，不发生在提交，而发生在删除、复制、回收这些收尾动作。Approvals 对这些动作其实加了不少保护，只是平时不显眼。
参考入口：
enterprise/approvals/models/approval_request.pyenterprise/approvals/models/approval_product_line.pyenterprise/approvals/tests/test_approvals.py
一、已批准请求不能删，只能归档
_unlink_except_status_is_approved() 直接挡住 approved request 的删除，提示“已批准请求请归档”。这很关键：审批结果已经是业务事实，删除会破坏审计链；归档只是从主视图退场，不是否定它曾经存在。
二、附件不是跟着 ORM 自然消失，而是显式清理
unlink_attachments() 会专门查 ir.attachment(res_model='approval.request') 再删除。测试 test_unlink_approval 还覆盖了带附件、带二进制自定义字段的草稿删除场景，确保不会残留脏附件或因为 binary 字段导致 unlink 报错。
这说明一个常见误区：很多人以为“删主记录就行，附件会自己走”，但 Odoo 在这里是显式补清理逻辑的。
三、产品行是额外子表，批量删单时必须一起处理
当分类启用了产品维度，请求会挂 approval.product.line。approval.request.unlink() 先删 product_line_ids 再走父类；测试 test_unlink_multiple_approvals_with_product_line 专门验证批量删除不会留下孤儿产品行。
四、复制不是深度重走流程，而是生成新草稿语义
copy_data() 会把名称改成“原名 (copy)”。这看似小事，其实代表复制的语义是“再提一张类似请求”，而不是“把原审批状态克隆一份”。复制后仍应重新确认、重新走 approver 流程。
五、实战建议
- 需要保留审计痕迹时，禁用“删已批单”的人工习惯，统一用 archive。
- 自定义审批扩展时，记得检查关联附件和子表是否跟着清理。
- 复制只适合复用数据骨架，不适合复用审批结论。
六、结论
Approvals 在删除、附件、产品行和复制上的处理，看起来是收尾细节，实际上是在保护审批链条的完整性：业务事实可退场，但不能被静默抹掉。
DISCUSSION
评论区