我的主业是 Java 后端，写惯了 Spring 和中间件，去年之前从没想过自己会发布一个 Chrome 插件。事情的起点很小：团队每天要读的英文文档太多，市面上的工具要么把整页替换得面目全非，要么按月收订阅费——而我们一个月用不了几次，订阅纯属浪费。
第一步：先做减法，找到真正要解决的问题
动手之前我把痛点拆了拆，发现核心诉求其实只有两个：
- 双语对照——不是不要原文，是要「译文提速、原文兜底」
- PDF 不乱版——技术资料一半是 PDF，翻译完排版散架等于没翻
市面工具在这两点上都有取舍，而这两点恰好都是工程问题，不是算法问题。
第二步：后端思维做前端活
作为后端写浏览器插件，最有意思的是思路迁移：
- 把「翻译服务」当微服务设计：请求排队、失败重试、结果缓存，这些后端的老三样直接搬了过来
- 上下文窗口当连接池管：长文档不能整篇塞给模型，分段策略本质上是「批处理+断点续传」
- 配置即代码：术语库做成可导入的 JSON，团队共用一份
前端部分老老实实用了原生内容脚本 + 少量状态管理，没有引入重框架——插件的生命周期太短，框架的启动成本不划算。
第三步：上架前最容易被忽略的事
审核被拒过一次才明白：商店对「推广行为」的判定比想象中严格，描述里不能有诱导性文案，权限申请要和功能严格对应。另一个教训是保排版 PDF 翻译的测试覆盖——不同生成器产出的 PDF 差异极大，我们的方案是按「文本层完整度」分三条处理路径，才把失败率压下来。
一些心得
回头看，这次自研给我最大的收获不是工具本身，而是验证了一个路径：后端工程师做小工具，优势不在前端技术，而在把工具当「服务」设计的思维。排队、缓存、降级、计量，这些日常后端功课，放到浏览器插件场景里全都是竞争力。
工具最终做成了 Chrome 插件「随心翻译」，按量计费模式。如果你也有一类反复出现的痛点，不妨按「拆诉求→服务化设计→小步上架」的路径试试，成本比想象中低。
