关于技术探索与实践的一些经验：一个老广外包仔跳进甲方后的碎碎念

去年十月某个周五晚上十点半，我瘫在珠江新城某写字楼的工位上，盯着屏幕上一堆红得发紫的报错日志，手边那杯凉透的益力多已经空了。老婆刚发来微信：“今晚回不回？明早还要送仔去幼儿园。”
我回了个“快了”，然后默默关掉 IDEA，心里骂了一句：“又他妈是前端资源路径问题。”

那时我还是个外包仔，在一家给银行做内部系统的乙方公司干了整整三年。月薪15k，房租3500（老城区恩宁路的老破小），通勤地铁挤到怀疑人生。每天的工作就是：改 bug、对需求、怼测试、被产品经理画饼。技术？别笑了，能跑就行。

但就在那个晚上，我收到了 HR 的微信：“offer 定了，22k，下周一入职。”
——我终于跳进了甲方。

---

从“能跑就行”到“资源加载都要压测”

刚进甲方那会儿，我以为自己是来养老的。结果第一天晨会就被打脸。

我们组负责一个企业级 SaaS 平台的后端模块，但因为历史包袱重，前后端耦合得像肠粉里的虾仁——分都分不开。更离谱的是，前端静态资源（JS、CSS、图片）全扔在后端 Tomcat 的 webapp 目录下，每次发版都要重启服务。运维大哥一看到我就翻白眼：“你又来搞我服务器？”

有一次上线，前端同事改了个图标，结果忘了更新缓存策略，导致全国几百个分支机构的用户刷出来全是 404。老板直接在大群里@我：“为什么用户打不开页面？！”
我一脸懵，跑去问前端小哥，人家耸耸肩：“哦，我本地 dev 模式没问题啊。”

那一刻我才意识到：在甲方，没人管你是前端还是后端，系统挂了，锅就是你的。

于是，我开始疯狂补课。不是为了卷，是真的怕背锅。

我翻遍了公司内部的文档库，发现早在两年前就有团队提过“静态资源分离”的方案，但因为“优先级不高”一直搁着。我咬咬牙，拉着前端和运维开了个会：“咱们把资源全迁到 CDN 上，用 hash 命名，加 long-term cache，再配个 fallback 机制，行不行？”

前端小哥眼睛一亮：“你懂这个？”
我说：“不懂，但我被坑怕了。”

我们花两周搭了个 PoC：用 Webpack 打包前端资源，生成带 content hash 的文件名；Nginx 配置缓存头；后端只返回 HTML 模板，资源路径通过配置中心动态注入。上线那天，我紧张得手抖，结果零故障。

后来老板在周报里点名表扬：“这次资源加载优化，首屏快了 1.8 秒。”
我心里冷笑：要不是被逼到墙角，谁愿意搞这些“额外工作”？

---

工具不是越多越好，而是“刚好够用”

很多人以为甲方就是高大上，什么 ArgoCD、K8s、Service Mesh 全拉满。现实是：我们连 Git 分支模型都没统一。

刚来时，我发现同一个项目有三个 Git 仓库：一个给测试用，一个给生产用，还有一个是“主开发库”——但没人敢动。合并代码靠人工 diff，发布靠手工打包 WAR 文件上传到 FTP。我差点以为穿越回 2010 年。

有一次，我改了个小接口，本地跑得好好的，上了测试环境却 500。查了半天，发现测试环境的数据库字段少了个索引。运维说：“哦，那个环境是我们实习生搭的，没跑初始化脚本。”

我当场裂开。

于是我和几个有同样痛点的同事偷偷搞了个“工具链自救小组”。目标很简单：让重复劳动自动化，让人为失误归零。

我们先从最痛的点下手——部署。用 Jenkins 写了条 pipeline：代码推到 release/* 分支 → 自动跑单元测试 → 打包 Docker 镜像 → 推到私有 Harbor → 调 K8s API 滚动更新。虽然只是基础操作，但在我们这儿已经是“黑科技”。

前端同事也加入进来，他们用 Vite + TypeScript 重构了旧项目，还搞了个内部组件库。以前改个按钮要三天（因为要兼容 IE11），现在一天能出五个页面。

最让我感动的是，运维大哥主动帮我们申请了 Grafana + Prometheus 监控面板。他说：“你们搞干净点，我也少加班。”

你看，工具的价值不在于多新多酷，而在于它能不能把人从泥潭里拉出来。

---

前端？后端？在甲方眼里都是“开发”

很多人问我：“你一个 Java 后端，为啥要管前端的事？”

我的回答是：因为在小团队里，没人替你兜底。

我们组总共六个人，两个后端，两个前端，一个测试，一个产品经理（兼运营）。老板的要求就一句：“月底前上线新模块，用户体验要好。”

什么叫“用户体验要好”？是接口快？是页面炫？还是交互顺？没人定义。于是我们只能自己定义。

我开始学看 Chrome DevTools 的 Network 面包，分析哪些资源加载慢；研究 Lighthouse 报告，看怎么提升性能分；甚至帮前端写了个简单的 Mock Server，让他们不用等我接口就能开发。

有一次，前端小哥问我：“这个 API 返回的字段太多，页面卡顿，能不能分页？”
我说：“可以，但你要告诉我用户到底需要看哪些数据。”
他愣了一下：“……其实他们只关心最近三天的订单。”

你看，技术问题背后往往是业务理解的问题。 如果我不去问、不去看、不去试，光在后端闭门造车，永远做不出好产品。

后来我们定了个规矩：每个功能上线前，所有人必须用自己的账号走一遍全流程。后端也要打开浏览器，点按钮、填表单、看加载动画。
“别把自己当码农，当用户。”——这是我老婆教我的（她是个 UX 设计师）。

---

资源有限，所以更要精打细算

在乙方时，老板常说：“客户预算有限，功能能省则省。”
在甲方后才发现：甲方的预算也不多，只是换了个说法——“降本增效”。

我们没有无限的服务器、没有专职的 DevOps、没有 AI 大模型团队。所有资源都要精打细算。

比如，我们想上 Redis 缓存，但公司 Redis 集群资源紧张。怎么办？我们先用 Caffeine 做本地缓存，命中率 85% 以上才考虑远程缓存。结果发现，大部分查询根本不需要 Redis。

又比如，前端想上微前端拆分项目，但评估后发现团队规模撑不起架构复杂度。最后我们选择用 Monorepo + 模块联邦（Module Federation），既隔离了代码，又避免了运维爆炸。

技术选型不是比谁用的框架新，而是比谁在约束条件下活得更好。

上周五晚上，我又加班了。但这次不是修 bug，而是在试一个新的构建工具——Turborepo。它能并行执行任务，还能缓存产物。我跑了一次 build，比之前快了 40%。虽然只是 30 秒的差距，但乘以每天 20 次构建，就是 10 分钟。10 分钟能陪儿子拼完一盒乐高。

这大概就是技术探索的意义：不是为了炫技，而是为了让生活多一点喘息的空间。

---

写在最后：技术人的“务实浪漫”

从外包到甲方，月薪从 15k 到 22k，听起来挺风光。但只有我知道，这背后是无数个深夜查日志、周末看文档、开会扯皮的疲惫。

我曾经很焦虑：是不是该学 Rust？要不要转 Go？大模型会不会取代 CRUD 工程师？
后来想通了：技术是手段，不是目的。

在广州这种务实的城市，老广们讲究“识做”——知道怎么做才有效。写代码也一样：能解决问题、能减少痛苦、能让团队走得更稳，这就是好技术。

所以，别被“前沿”绑架。
前端框架三年一换，工具链月月更新，但用户要的从来不是 Vue 还是 React，而是“点一下就出来”。

资源有限？那就聚焦核心。
工具混乱？那就从小处优化。
前后端撕逼？那就坐下来一起看数据。

技术探索不是一场冲刺，而是一次次微小的实践积累。每一次你主动去搞懂一个报错、优化一个加载、写一个自动化脚本，都是在为未来的自己铺路。

现在，我依然住在恩宁路的老房子里，早上送完孩子顺路买个肠粉，晚上回家还能闻到巷口糖水铺的姜撞奶香。
但不同的是，我不再害怕凌晨三点的报警电话——因为我亲手加固了系统的每一块砖。

共勉，各位还在泥泞中前行的同行者。
愿你的代码少些 bug，生活多些甜。