API开发工具箱：更快调试，更早上线
JWT调试、HTTP状态码、JSON格式化、Base64编码和URL编码——API开发者的必备浏览器工具。
下午3点，你的API返回了401。Token看起来是有效的。端点是对的。请求头也看着没问题。
把JWT粘贴到解码器里，问题立刻显现：exp声明在12分钟前过期了。Token刷新逻辑有个bug。
5秒钟的解码刚刚省下了一小时盯代码的时间。
JWT调试是每天的工作
如果你使用任何现代API，就会不断接触JWT。登录令牌、服务间认证、OAuth流程——到处都是。
问题是JWT看起来像一串无意义的乱码：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
它有什么声明？什么时候过期？用什么算法签名的？光看是看不出来的。
粘贴令牌，立刻看到头部、载荷和过期时间。不用安装库，不用写代码。直接给你答案。
HTTP状态码：不止200和404
快说——401和403有什么区别？502和503呢？什么时候该返回409，什么时候返回422？
大多数开发者知道常见的状态码，但API会返回几十种不同的状态码。当你收到一个意想不到的429或令人困惑的307时，需要准确知道它的含义。
HTTP状态码参考告诉你每个代码的含义、使用场景和常见原因。比Google搜索快，而且不用在Stack Overflow的讨论中筛选。
JSON格式化不是可选的
API发送JSON，API接收JSON。大多数情况下，JSON以一行压缩的、没有空格的形式到达。
{"users":[{"id":1,"name":"Alice","roles":["admin","editor"],"settings":{"theme":"dark","notifications":{"email":true,"push":false}}}]}
试试在里面找一个丢失的逗号。或者检查某个嵌套字段是否存在。或者比较两个响应。
粘贴压缩的JSON，得到适当缩进的格式化结果。现在你可以真正阅读它、发现错误、比较结构了。
Base64：认证头的秘密
API认证经常涉及Base64编码。Basic Auth头是username:password的Base64编码。JSON载荷中的二进制数据用Base64编码。证书内容、Webhook签名、加密值——都是Base64。
当出问题时，你需要解码实际发送的内容。或者编码一个新值来测试。
Base64编码/解码器双向即时处理。粘贴编码字符串，看到原始值。输入新值，得到编码版本。
常见调试场景：Basic Auth头失败了。解码后发现密码末尾有个换行符。在代码中找到这个问题要花更长的时间。
URL编码会变得棘手
带特殊字符的查询参数需要URL编码。空格变成%20（或+），&号变成%26，斜杠变成%2F。
这在以下情况很重要：
- 构建包含用户输入的搜索端点
- 查询参数本身包含URL（回调URL、重定向URI）
- 调试参数为什么解析不正确
- API密钥包含特殊字符
URL编码/解码器精确显示编码/解码后的样子。在调试OAuth回调URL时特别有用，因为这些URL经常是"URL中的URL"，双重编码后变得不可读。
真实的调试流程
这些工具如何融入实际的API调试过程：
- 请求失败 — 检查HTTP状态码含义
- 认证问题？ — 解码JWT检查声明和过期时间
- 载荷问题？ — 格式化JSON检查结构
- 头部问题？ — 解码Base64认证头
- URL解析？ — 解码URL检查参数编码
每个步骤只需几秒。替代方案——写一次性脚本、安装CLI工具或翻文档——需要几分钟到几小时。
保持打开
我把这些工具放在浏览器的固定标签页里。不是因为我不能在Python里做Base64编码或在VS Code里格式化JSON。我可以。但切换到终端、写个快速脚本、运行它——这会打断调试的流程。
这些工具就是调试速度本身。粘贴，看结果，理解问题，修复代码。最快的调试循环。
API开发50%是写代码，50%是弄清楚为什么写的代码没有按预期工作。合适的浏览器工具不是替代IDE或调试器——而是通过让"弄清楚"的部分更快来补充它们。