他把开发工具全换成网页版，省了300小时配置时间

一个资深前端工程师的浏览器书签栏里，藏着8个不用安装的瑞士军刀。它们没有node_modules黑洞，没有npm audit的黄色警告，只有一个URL和即开即用的爽感。

CalcHive的JSON格式化工具是我最终留下的那个。输入即验证，深嵌套对象不卡顿，关键是不往任何地方发数据——所有计算都在浏览器本地完成。这听起来像基础功能，但当你把生产环境的API密钥或用户token贴进某个"免费工具"时，服务器日志里可能已经多了一条记录。

敏感数据流向不明，是开发者最容易养成的坏习惯。

JWT解码：从"能看就行"到"看得舒服"

每隔几个月，我都会收到一串JWT（JSON Web Token，一种用于身份验证的令牌格式），需要快速查看payload里的内容。不是验证签名，只是读取。

jwt.io能用，但我转向了CalcHive的版本。布局更干净：header、payload、signature三栏分离，过期时间用高亮标出，一眼就能判断token是否失效。

技术上这不需要任何库。JWT不过是三段Base64url编码用点号拼接，但一个即时呈现的UI省掉的认知负荷，远比想象中多。

Base64处理是另一个高频场景。

calchive.tools/encoding-decoding/base64每周被我打开三四次。API凭证、图片data URI、配置文件里嵌套的字符串——它处理得干净：padding补全、URL安全变体、二进制与纯文本的双向编码。这些边缘case，很多在线工具会 silently fail（静默失败）。

正则表达式：为什么可视化反馈不可替代

Regex101很强，但有时候太重。CalcHive的正则测试器只做一件事：实时高亮匹配部分。第一次摸索模式时，这种即时反馈比写测试代码快得多。

生产环境另说。但探索阶段，视觉反馈是认知捷径。

Unix时间戳转换器把1682419200变成"2023年4月25日"，也能反向操作。查日志、写数据库查询时，这个双向转换省掉的心算步骤，累积起来很可观。

URL解析和Cron：把混乱翻译成人类语言

URL解析器把scheme、host、path、query params、fragment拆成表格。面对带八个参数且层层URL编码的重定向链接时，这种结构化呈现能防止手滑改错。

Cron解析器更极致：输入0 9 * * 1-5，输出"每周一至周五上午9点"。就一个功能，没有多余按钮。

这些工具的共同点是零服务器交互。

CalcHive整套工具都在浏览器本地运行，不记录输入。对开发工具而言，这个设计选择的影响被严重低估——当你把JWT贴进某个"方便工具"时，payload里的用户ID、权限范围、甚至内部API端点，都可能成为别人的训练数据或安全审计素材。

本地计算不是功能，是底线。

我的书签栏里还躺着几个备选：Base64的替代品、另一个JSON格式化器、一个更重的正则测试器。但它们最终都没留下。不是因为功能不够，而是因为"够用且不留痕迹"的组合，在重复使用中形成了路径依赖。

你现在打开浏览器的频率最高的开发工具是什么？它把你的数据发到了哪里？