北京
三周前的周日晚上，我为同一个副业项目起了第九次名字，却仍然没在正式文档里落下一个字。当时我打开一个叫 amzapp 的文件夹，想找一份已经保存过的开发者密钥。结果文件夹不止一个，一共跳出六个：larify、arify、amz、Amzs、skayel360、brevlin。每一个文件夹里都存着同一款亚马逊卖家利润追踪器的局部代码，没有哪一个容纳了全貌。那个晚上我花掉的第一小时，不是用来写新功能，而是用来重新把自己装回这个项目——哪个文件夹是当前版本、哪套密钥还在生效、上回试到了哪一步、失败的原因是什么。
对于在正职工作间隙维护副业的人来说，这种感觉并不陌生。搁置几周再打开，头脑里的上下文早就被冲刷干净。项目文件夹像散落一地的拼图碎片，每一片都真实，但拼不起来。那个晚上我重复了太多人做过的事：凭记忆在六个目录里翻找，最后终于做了最初就该做的事——停止回忆，把所有东西写进同一个地方。一个单页的真相文档。
事后复盘，真正的阻碍从来不是亚马逊的 Selling Partner API 本身。这套接口确实棱角分明：四套登录入口外观一模一样，授予的访问权限却完全不同；两种凭据类型听起来可以互换，实则被设计成互斥；三个独立的审批流程藏在一扇登录门背后。但这些技术细节并不解释几个月的原地踏步。解释它的是九个名字、六个文件夹，以及它们之间没有任何一条交叉引用。每一次开发会话都是从零开始，因为我从来没有造出一个能容纳全部真相的唯一位置。
那段经历里，有一张表值得所有接触过平台 API 的开发者拿走复用。任何同时拥有开发者控制台和业务控制台的平台，都可能埋藏着同样一类陷阱。我花掉大量时间建立在一个错误假设上：开发者控制台里的全部权限，对于卖家的真实数据毫无作用。两套系统共享同一个登录页面，却绝不共享任何实际权限。两个凭据里有一个带着永久式的销毁开关。应用需要 client id 和 secret，而每一个对接的卖家还会给出一个独立的 refresh token。调用任何接口，这两样缺一不可。有一个细节极少出现在任何 API 入门的醒目位置：重新生成一个新的 refresh token，并不会让旧的 token 失效。亚马逊在控制台里坦然写明了这一点。这意味着一旦某个 refresh token 泄露，再次授权无济于事。唯一能中止它的是轮换掉 client secret，因为 token 交换根本无法脱离 secret 单独进行。我如果没有把控制台里那段细小的说明读两遍，就永远不知道这一点；如果没有把它记录在随时能找到的地方，三周后再回来就会再次忘掉。
最终打破项目停滞的，是一个文件。一张单页，写清了每一个身份、每一个凭据、每一把密钥存放在哪里，以及此前哪些假设已经消耗了真实时间。每次任何一环发生变化，这张单页就在同一刻被同步修改，从不拖延到下一次会话。API 本身没有因此而变得更简单，只是我每次回到项目时，不再需要重新发现同样那三个事实。那个账本数字是我下决心解决这个问题的起点：九个名字，六个文件夹，零交叉引用。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
