Steam 交易报错，重新发送前先查这几处

交易报价发出后出现错误。对方说没有收到，而你的库存里物品还在。再次点击之前，先打开已发送的报价列表。仅凭屏幕上的错误，不能断定报价没有创建。

报价创建、本人确认、对方接受和物品交付是不同阶段。先弄清已经走到哪一步，才能决定是查看原报价、重新创建，还是向客服询问。在原因不清楚时，我不会先去改账号设置。

本文依据 2026-09-05 核对的 Valve 文档。文中的情境只是解释用的假设，不是对实际账号错误率、找回时间或 Steam 整体故障规模的测量。

先记下错误前按了哪个按钮#

先记清楚：是物品选择页面没有打开，还是点击 Make Offer 后出错，或者是在接受收到的报价、用手机确认时出错。错误文字按原样记录，时间要带上时区。“确认后出错”不如实际按钮名称具体。

Steam 交易说明介绍了从库存的交易报价页面或好友资料创建报价，并根据账号情况完成手机应用或电子邮件确认。通过创建页面，不等于报价已经发送。即使重新打开页面后错误消失，也不要为了复现而再次发送；先查看现在留下的记录。

报价列表和物品移动记录不是一回事#

在库存的 Trade Offers 中，如果是自己发出的，就查看 Sent Offers；如果是接受收到的报价时停住，就查看 Incoming Offers。当前列表里找不到时，再检查报价历史；已经完成的物品移动，则要到交易记录中核对。Steam 交易帮助也把这些入口分开列出。

同时看交易对象账号、创建时间和发送/接收的物品，避免与以前相似的交易混在一起。下面的表不是错误编号解释，而是当前画面中要确认的状态。

如果列表加载失败，应该记录为“还没确认”，而不是“没有报价”。页面正常打开后仍找不到该报价，是另一种情况。对方说“没收到”时，先分清是没看到通知、列表里没有报价，还是确实没有收到物品。

Steamworks IEconService 文档也区分 GetTradeOffers 返回的发送/接收报价和 GetTradeHistory 返回的交易历史。按本文检查，不需要为此申请 API key。

显示“等待中”时，要看还差谁的动作#

根据交易报价 FAQ，完成必要的本人确认后，报价才会发送，而且不能关闭这项确认。如果确认还没完成，应打开原请求，不要重复创建。也不要一次批准多个请求，先重新核对交易对象和双方物品是否符合约定。

如果你已完成本人确认，只是在等待对方回应，报价已经创建。对方还没有选择，不必把它当成自己账号的发送错误。双方接受后，Steam 暂缓交付物品，则是另一种状态，相关条件见交易保留与市场保留的说明。

CS2 不应直接套用一般的交易保留期限。下面的交易保护说明表示，CS2 使用 Trade Protection，而不是原来的交易保留或托管。仅凭“pending”这个词，不能推算几分钟或几天后一定解决；如果当前页面显示结束时间或需要完成的事项，应按页面提示处理。

同名物品还在，旧报价也可能已经失效#

Valve 说明，同一件物品可以放进多份报价，但其中一份被接受后，包含它的其他等待中报价会变成无效。如果该物品已经通过另一笔交易转出，或在市场上卖掉，也不能再接受原报价。仅仅把物品放进报价，不会提前把它从库存中扣掉。交易报价 FAQ

假设同一张卡牌先后放进发给 A、B 的两份报价。B 的交易完成后，A 不能再用那张卡接受旧报价。之后重新得到一张同名卡，也不能假定旧报价会自动指向新卡。当前库存里有同名物品，和旧报价仍然有效，是两件事。

对方原本要给你的物品也要这样检查。我的物品还在，不表示对方没有卖掉或换走对方的那件。先确认双方对应物品和报价状态，再判断原因。如果改成了新物品，就是新报价；物品、属性和数量都要重新核对。单件物品的交易日期和限制标记也要另行查看。

不允许的组合，不能靠改设置解决#

2026-09-05 核对的交易保护说明将支持游戏写明为 CS2。一份交易中的物品必须属于相同的保护等级，因此不能把 CS2 物品与不支持保护的其他游戏物品放在同一交换组合里。每件物品单独可交易，不代表它们的组合也被允许。

不能把这份组合拆成两笔，再建议其中一方先发送。原本同一报价里的对价会变成两份分开的约定，应当重新讨论交易组成。

收到的 CS2 物品处于7 天保护期时，消费、修改和再次转移都会受到限制。这不是服务器错误的恢复时间。要分别看它能否在游戏中使用，以及能否再次交易。

如果错误明确提到账号限制，应查看 Steam 限制说明和实际显示的文字。Valve 说明交易时通常会显示原因，客服不能替你修改限制。不要拿别人的等待日期来代替自己页面显示的日期。

关闭 Steam Guard 或删除手机验证器不是刷新操作。删除 Cookie 或换浏览器，也可能根据验证条件触发新设备限制；具体例外意味着并非人人都会得到相同结果，但不能把这些操作一概推荐为原因不明的交易错误的第一处方。

先确认状态，再决定重试或取消#

重新打开页面查看，和创建一份新交易请求，是两种不同的动作。只要原报价仍有效，就先查看它。只有在列表、历史和交易记录都能正常查询、确认找不到原报价，且账号和物品条件也没有问题时，才可以考虑重试。下一次操作后仍要重新检查记录。

逐项确认和上一次相比发生了什么变化，例如是否重新约定了物品，页面显示的限制是否真的结束。连原报价是否仍存在都不清楚时，不要创建重复请求。如果已经创建了多份，也要先核对物品和数量，不要轻易对对方说“随便收哪份都行”。

取消也分情况。等待对方回应的待处理报价，和双方接受后处于交付等待的交易，不是同一个操作。Valve 的交易保留说明指出，取消后者会产生保护性的交易限制。受保护交易的撤回又有单独的范围和限制。不要为了测试页面刷新而把报价全部取消或撤回。

未经官方文档核对的错误编号解决表，不应拿来代替状态诊断。工具里的状态值和 Steam 错误编号不保证含义相同。可以记录编号和文字，但仍要确认它们是否确实描述了当前状态。

只有外部网站还在处理时，要分开看两边状态#

分别查看 Steam 记录和外部服务的订单、入库或出库状态。假设 Steam 已确认物品移动，而网站仍显示处理中，应向网站询问它自己的状态。再次发送物品不是修正第一笔交易显示，而是新增一次物品移动。

联系支持时，把外部订单号与 Steam 报价地址或标识分开记录。写清“Steam 已完成、网站仍处理中”这类你亲自看到的状态，才能知道该向哪一方问什么。不要假定一方客服可以查看另一方的内部记录。

把物品发到所谓的测试账号，或应要求先批准一份测试交易，都不是查询记录。查看交易 URL和被要求提供密码、验证码是两回事。Valve 的建议说明 Steam 交易界面不能转移金钱。报价消息里写着外部付款承诺，也不能证明对方真的会付款。

联系客服时，把已确认和未知部分一起写清楚#

下面是填写咨询内容的示例，不是实际故障案例。方括号内只放你亲自确认过的内容，不知道的项目就保留为未确认：

> 在[日期·时间·时区]的[创建报价／接受收到的报价／应用确认]步骤中出现错误。错误原文是[文字]。目前这份报价在[列表·历史]中显示为[状态]。交易记录显示[确认物品已移动／查询正常但没有该移动／查询失败]。物品说明中有[条件]。之后我实际进行了[操作]，并确认了[结果]。

对方告诉你的内容，要和你亲眼看到的页面分开记录。私人咨询可以附上相关报价地址；公开发帖时，应遮住账号信息、邮箱等不必要的资料。密码、验证码、登录 Cookie 和找回代码都不需要。

在官方 Steam 交易支持中选择最接近出错阶段的入口。如果怀疑账号控制权已经丢失，不要继续普通重试，先看包含账号找回的安全指南。如果只剩外部网站的入账或处理状态，就把两边的记录交给该服务。提交咨询不保证回复时间或物品能够找回。