先限定是哪一套撮合规则
阅读币圈现货交易所的资料，容易把不同平台的同名字段当成同一规则。本文只解释Coinbase Exchange官方文档里的自成交防护，即STP，不将其推广为所有平台的通用机制，也不评价平台是否适合某位读者使用。
该文档明确，同一用户的两张订单相遇时不会彼此成交；发生冲突时，后到的主动订单所带STP指令优先于先前挂在订单簿中的订单。这描述的是系统怎样处理冲突，不是让使用者制造冲突，也不意味着配置了STP就已经满足所有行为规范。
数量调整与实际成交不是一回事
文档将dc列为默认处理：取消较小的订单，并按其数量扣减较大的订单；两者数量相同时则取消双方。市价单另有依资金和数量字段而定的说明，不能机械套用这一概括。防护造成的减少与取消，也不能记作两张订单已经互相完成交易。
例如，只看到一张订单的显示数量前后不同，仍缺少变化原因这一层信息。本文建议在阅读已有日志时，分别保留订单标识、数量变化、结束原因和成交明细。这个整理建议用于理解记录，不提供下单步骤，也不通过构造真实订单演示自成交。
另三种处理分别保留或取消哪一方
co会取消先前的挂单，让较新的主动订单继续执行；cn会取消较新的主动订单，让旧挂单保留；cb则取消双方。读这些名称时，应先明确新旧订单指什么，再看取消影响哪一方，不能只根据中文界面中的取消二字推断全部订单都被撤去。
这里的继续执行也不是已经成交的同义词。整理文档时，可以把处理结果写成旧单取消、新单保留待后续处理等描述，不应跳过后续结果直接填入成交额。本文不列哪种选项更有利，因为那会把规则说明变成不必要的交易策略建议。
订单结束仍需核对成交与结算字段
Coinbase的撮合说明把received、open、done放在订单生命周期中解释，其中done不能简单翻译成全额成交。其单笔订单查询文档还分别列出filled_size、done_reason和settled：它们描述已成交数量、结束原因以及资金是否已交换并结算，回答的问题并不相同。
因此，一张清晰的资料卡不应只留一个成功或失败标签。可以将是否仍可参与撮合、已成交数量、结束原因、结算标记分别存放。如果来源没有给出某字段，就标明缺失；不能为了补全表格，用done替代满额成交，或用数量变化推导已经结算。
快照和缺失响应都不能过度解释
单笔订单文档提示，开放订单可能在请求与响应之间改变状态；如果订单被取消且没有发生过匹配，查询还可能返回404。这说明一次响应只是带有条件和时点的观察，不能把查不到直接扩写为从未存在，更不能据此自行补写一笔成交。
读者可以在笔记中保留资料版本、字段原名、观察时间和未能确认的事项，避免把状态翻译成过强结论。本文仅基于公开文档解释订单记录，没有查询私人账户、进行开户、充值或交易，也不涉及刷量、对敲或规避平台限制的方法。涉及具体订单异常，应由有权访问记录的人员依正式流程核对。