先选能回答问题的记录
例如你想知道一件物品是否送出，不应只看报价是否从等待列表消失。
| 记录 | 可以回答 | 不能单独证明 |
|---|---|---|
| 交易历史 | 已完成交换的记录 | 任意报价都已接受 |
| 报价历史 | 归档提议与状态 | 每条都有物品转移 |
| 市场历史 | 市场购买或出售 | 同一件事就是交换 |
先确定问题属于哪一行，再找证据。
Steam 交易历史与报价历史怎么区分？
已完成交换、等待提议、失效报价与市场买卖分别使用不同记录。先确定你要查的是物品转移还是一份提议的状态，再看对应历史；进入报价历史不等于实际完成交换。
在哪里查看交换与报价
官方帮助说明，可从交易报价页面或库存相关菜单查看交易历史。当前界面文字可能变化，按交易与历史功能识别，不需要寻找陌生接口。
等待报价与提议状态应在报价功能里核对，失效条目会进入报价历史。若你只想检查已有事实，就先读记录，不通过新发一条报价验证入口。一个菜单能打开，只说明你找到对应功能，具体结论仍依赖里面实际的对象和状态。
报价历史能证明什么
报价历史包含提议的状态线索，不是所有条目都代表完成物品转移。取消、失效与接受应按各自显示理解，不由归档位置统一推导。
如果某件物品已经不可用，报价可能失效；这需要结合其他记录解释，而不是看到历史里有它便写成对方已收取。保留原状态文字很重要，过度简写成交易完成会让后续核对建立在错误前提上。
市场买卖另查市场历史
市场购买或出售看社区市场历史，不要把它合并成交换历史。邮件收据可以辅助核对自己的市场记录，但不能单独替代官方账户里显示的结果。
活跃求购也不同于已完成买入，可看求购状态。同一个物品名字在多处出现时，先分清记录类型与方向，再决定这些条目是否涉及你真正要查的事件。
匹配方向账户与具体物品
核对自己的账户、对方账户、送出与收到方向、完整物品版本及数量。时间按页面实际显示使用，有时区说明才据此解释，不要自行加一个没有来源的 UTC 标签。
物品名称核对与库存层级区别可帮助避免把相似标签或网站记录当成同一 Steam 操作。私人账户标识与完整收据不需要公开，描述相关字段即可。
比如一条记录是送出，一条是收到，即使物品文字相同也不能先认作重复。把方向与对方账户一起读，能减少将不同事件误合并的风险；之后再核对页面显示的数量和时间。
保存结论不混合规则
最后记录你找到了哪类历史、哪条状态以及它实际支持的结论。没有确认完成转移时，就不要用一个归档提议补成成交事实。
当前 CS2 的交易保护有独立条件。先确认是否已有完成的 CS2 交易，再核对适用条件与后果；不是任何历史条目都能恢复。按记录类型处理，可以减少重复操作和不必要的争议。
先认清记录类型，再处理相应问题。
资料来源与当前规则
资料核对日期：2026 年 11 月 2 日。标签与位置可能随客户端版本及语言变化；请在自己的当前界面中核对所述状态。