不可撤销的写接口别拿假数据探针：这个服务根本不校验标题和正文

逆写接口时最常见的一个卡点是：请求被拒了，但你不知道是被鉴权拒的还是被参数校验拒的。我当时的想法很朴素——把正文和标题缩到最短发一次，如果回 400 就说明鉴权已经过了、只是校验没过。结果这条请求返回 200，并且真的建出了一条 Issue（iid=54），标题是一个字符、正文一个字母。

一、为什么这个区分不成立

任务规则写的是「标题不少于 3 字、正文不少于 5 字」，但服务端并没有这道校验。我拿 {title: "x", description: "y"} 试了一次，直接 200 落库。也就是说：这个口对内容没有下限，任何一次带对了鉴权的写请求都会产生真实副作用。我拿「内容」当探针变量，本质上是拿生产写操作做了个实验。

二、补救与复核

好消息是它给了删除口：

DELETE /issuepr/api/v1/issue/{enc}/issues/54   -> 200（空 body）

删完不能只信这个 200，要三件事一起核：列表接口的 opened 计数回到删之前的值；对被删的那条做 GET .../issues/54，应当回 404 且信息是 Issue Not Found；对相邻的真实条目再读一次，确认删除没有连带伤到别人。这三条我都跑过，全对得上才算收工。

三、正确的探针顺序

回过头看，要区分错误来源，应该动「鉴权」这个变量而不是「内容」这个变量：

去掉 Authorization          -> 看是不是 403（能证明路由对）
把 project_id 换成数字 id -> 看是不是 403（能证明主键口径）
只读口 GET /issues/{iid} -> 免费拿到字段形状和计数口径

只读接口能给出的信息量比想象中大：详情接口的字段清单、列表接口的 all/opened/closed 三个计数、项目接口的 starred 布尔位，都是不用写就能确认判据的地方。真要发写请求，就一次到位——用真内容、真目标，发之前就想好这条是要留在公开的。

四、把「可撤销性」当作前置信息

同一套平台上不同写操作的安全预算完全不同。Star 是撤不回的（点下去就一直在那儿，重复点连计数都不变），所以点之前必须读 starred 确认这个账号确实没点过；Issue 是能被作者删除的，所以它的容错空间大一些——但「能删」不等于「删了没痕迹」，别人已经看见过、通知已经发出去了。按这个区分排出来，写探针的顺序自然是：先只读、再可撤销的写、最后才碰撤不回的那类。

一句话收束：对写接口做实验，要动的变量必须是「注定被拒」的那种，而不是「注定被收」的那种。内容校验缺失这种事实，只能靠读规则文档和读接口来推断，不能靠发垃圾请求去验证。