开发调试常用的在线工具：JSON、正则、时间戳与 JWT 怎么用
开发时最常临时用到的在线工具就那么几个：JSON 格式化、正则测试、时间戳转换、JWT 解码、Cron 表达式。这篇讲清每个工具各自解决什么问题、常见误用，以及为什么有些数据不该粘进网页工具里。
开发时最常用的五个在线工具
日常写代码，有些事不值得为它装一个客户端：看一眼 JSON 结构、验一条正则、把时间戳换成日期、解一个 JWT 看里面写了什么、拼一条 Cron 表达式。这些事有个共同点——一次性、参数少、用完就走，正好是聚合型工具箱最合适的场景。
下面按「它解决什么、常见误用是什么」讲这五个，顺带说清哪些内容不该粘进网页工具。
JSON 格式化：先校验，再格式化
它的价值不是「变好看」，而是快速定位语法错误。一段报错的 JSON，格式化后错误位置通常一眼可见（多余的逗号、少了引号、括号不配对）。
常见误用是把接口返回的完整报文直接粘进去——里面很可能含 token、用户信息、订单号。要贴就先把敏感字段替换掉，或者只贴出错的那一段。
正则测试：看分组，不看整体匹配
正则工具的高价值处是高亮分组捕获，而不只是告诉你「匹配上了」。写提取类正则时，重点看每个捕获组拿到了什么。
两个常见误用：一是拿真实日志去测（日志里常有手机号、IP、内部地址），用构造的样例更安全；二是过度依赖在线工具的结果——不同语言的正则引擎对边界情况（回溯、贪婪、Unicode 属性）处理不同，最终以目标语言的运行结果为准。
时间戳转换：先确认单位，再看时区
时间戳工具翻车几乎都在这两点上：秒与毫秒搞混（10 位与 13 位），以及时区偏移（同一串数字在不同时区显示成不同日期）。
| 位数 | 单位 | 典型量级 |
|---|---|---|
| 10 位 | 秒 | 2001 年后至 2286 年前 |
| 13 位 | 毫秒 | JavaScript 常见（Date.now()） |
| 16 位 | 微秒 | 部分后端与日志系统 |
看位数就能判单位，比反复试快。换算后务必核对时区：服务端通常存 UTC，展示要给用户看本地时间，这两者差几个小时，很容易把「昨天的数据」算成今天。
JWT 解码：它只是「解码」，不是「验证」
这是最容易被误解的一个工具。JWT 的 Payload 是 Base64 编码而非加密——任何人都能解开看内容。所以：
一，别把敏感信息放进 JWT 的 Payload（它本身就是可读的）；二，解码工具只能告诉你「里面写了什么」，不能告诉你「这个 token 是否有效」——签名验证需要在服务端用密钥完成。
用它排查问题的正确姿势是：看 exp 有没有过期、aud/iss 是否符合预期、自定义字段是否缺。真实的生产 token 不要贴到任何网页工具上，这与把密码贴上去没有区别。
Cron 表达式：容易错的是「日」与「周」
Cron 有五个字段（分、时、日、月、周），最容易出错的是「日」和「周」同时指定时，多数实现是「或」的关系，而不是「且」。也就是说 0 0 1 * 1 表示「每月 1 号或每周一」，不是两者都满足。
用生成工具时，请它反过来把表达式解析成中文说明——读一遍「下次执行时间」比盯着五个数字可靠。
什么内容不该粘进在线工具
开发场景里，这几类几乎必出现在剪贴板里，也几乎都不该上传：生产环境的 token 与密钥、含真实用户数据的接口报文、内部域名与内网地址、以及未公开的代码片段。
稳妥做法是用构造数据替代真实数据：把手机号换成 13800000000，把 token 换成 xxx.yyy.zzz，把域名换成 example.com。真要看结构，结构用假数据也能看出来。完整的分类判据见在线工具的隐私边界；如果你更想把这些工具收进自己的入口页，可参考聚合链接是什么。
顺带一句：配色与前端工具
开发过程中还会频繁用到几个偏设计的小工具：把设计稿里的色值在 RGB / HEX / HSL 之间互转、生成一段渐变背景的 CSS、或者给卡片调一份柔和的阴影。这类工具在同一个工具箱里通常归到「设计工具」类目下，用法与坑见配色工具怎么用。
补一条使用顺序上的经验：先用在线工具把问题跑通，再考虑把它固化成脚本。同一个数据处理逻辑，如果一周要跑三次以上，写成本地脚本的总成本会低于反复复制粘贴；而如果只是排查一次，用在线工具打开就做，最省。判断分界线就是使用频率。
另外提醒一句：在线工具的便利容易让人形成依赖，但排查类工作往往需要可重复——同一个问题下次还想这么查一遍，就把命令记下来，而不是记住「我上次用哪个网站解的」。工具会变，命令不会。
常见问题
在线正则工具的结果能直接信吗？
当参考可以，当结论不行。不同语言的引擎对回溯、Unicode 属性、锚点语义处理不同，最终以目标语言的实测结果为准。
JSON 格式化后还是报错？
先确认贴进去的是完整报文而不是被聊天软件截断的片段；再看是不是 JSON5 / JSONC 这类允许注释的变体，标准 JSON 不允许注释。
时间戳差了一天？
八成是时区：换算时选了本地时区，而原始数据是 UTC。服务端存 UTC、展示转本地，这个约定要固定下来。
JWT 能只靠解码验证合法性吗？
不能。解码只是 Base64 还原，任何人都能做。合法性要靠服务端用密钥验签。
Cron 表达式在服务器上没按预期触发？
先看「日」和「周」是否同时写了（通常是「或」关系），再看服务器时区与表达式假定的是否一致。
这些工具能离线用吗？
看具体实现。轻量计算类（编码解码、单位换算、正则）常做成本地执行、断网可用；这也是挑工具箱时要验证的一条，方法见工具箱小程序怎么选。另外小程序端的开发类工具受审核类目限制，相关规则见小程序备案与审核指南。
小结
这五个工具属于「用完就走」的类型，价值在快而不在深。真正要养成的习惯是两条：用构造数据替代真实数据，别把生产环境的 token 与用户信息粘进任何网页工具。至于工具本身，一次性能用、结果可核对就够了；需要长期反复用的，值得固化成本机脚本。
鄂公网安备42010502001286号