从Java后端到React前端：我在成都踩过的工程化大坑

去年冬天，我还在成都一家电商公司做产品经理，每天和开发团队斗智斗勇，催着他们按时上线双11功能。结果双11刚过，老板突然找我谈话：“你不是总说懂技术吗？来带个前端工程化项目吧！”我当时内心OS：我懂的是Axure和PRD，不是Webpack和Babel啊！

但谁让我当初吹牛说自己“技术背景深厚”呢？毕竟转行前在阿里做过两年Java后端，对Maven、Spring Boot那套还算熟悉。于是，就这样，我这个前PM、现斜杠青年，开始了从Java世界跳进React深水区的奇幻漂流。

---

为什么前端工程化成了“生死线”？

事情起因其实挺简单。我们有个老系统，前后端混在一起，用JSP渲染页面，前端代码散落在各个Java Controller里。每次改个按钮样式，都要重新打包整个Java应用，测试还要走全套回归——上线一次，全组通宵。

更离谱的是，前端团队三个人，每人本地环境都不一样：A用VSCode + Webpack 4，B用Sublime + Gulp，C甚至还在手写HTML+jQuery。合并代码时，Git diff 能拉出半米长，光是 node_modules 冲突就吵了三天。

作为曾经的PM，我深知“一致性”是效率的命脉。于是我拍板：重构！搞一套标准化的前端工程化体系，从工具链到部署流水线，全部统一。

但现实很快教我做人。

---

工具链选型：别被“最新”迷惑双眼

一开始，我信心满满，觉得“既然是新项目，肯定要用最新技术栈”。于是直接上了 Vite + React 18 + TypeScript + Tailwind CSS。听起来很潮，对吧？

结果第一天就翻车。

Vite 确实快，但我们的老IE用户（没错，还有人用IE11！）直接白屏。而产品同事轻描淡写地说：“客户那边有几个政府单位，必须支持IE。”我当场裂开。

教训一：技术选型不是炫技，而是平衡。

最后我们妥协了：开发环境用 Vite 提升体验，生产构建切回 Webpack 5 + Babel，配合 @babel/preset-env 做兼容性兜底。虽然牺牲了点启动速度，但至少能跑。

// babel.config.js
module.exports = {
  presets: [
    ['@babel/preset-env', {
      targets: {
        // 兼容到 IE11
        browsers: ['> 1%', 'ie >= 11']
      },
      useBuiltIns: 'usage',
      corejs: 3
    }],
    '@babel/preset-react'
  ]
};

另外，作为Vim党，我坚决不用IDE。但团队里新人用VSCode，调试时经常因为路径别名（alias）配置不同而报错。于是我们在 jsconfig.json 里统一了别名：

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"],
      "@components/*": ["src/components/*"]
    }
  }
}

这样，无论用Vim还是VSCode，import Button from '@/components/Button' 都能正常工作。

---

Monorepo？还是多仓库？这是个哲学问题

我们有三个前端项目：管理后台、用户H5、小程序H5同构版。起初我打算用 Lerna + Yarn Workspaces 搞个 Monorepo，共享组件库、工具函数，看起来很优雅。

但很快发现，Monorepo 对 CI/CD 要求极高。每次提交，哪怕只改了管理后台，CI 也会跑所有项目的测试和构建。资源浪费不说，还经常因为一个子项目失败，导致整个 pipeline 卡住。

更惨的是，某次我误操作，把 package.json 的版本号统一升级，结果小程序那边因为依赖了某个不兼容的UI库，直接崩了。上线前两小时，测试群里疯狂@我：“线上白屏了！”

教训二：Monorepo 不是银弹，小团队慎入。

后来我们拆回独立仓库，但通过私有 npm 包（用 Verdaccio 自建）共享核心逻辑。比如把表单验证、API 请求封装成 @mycorp/utils，各项目按需安装。

# 发布内部工具包
npm publish --registry http://verdaccio.local:4873

这样既能复用，又互不影响。虽然多了点发布流程，但稳定性提升明显。

---

与Java后端的“爱恨情仇”

作为前Java程序员，我本以为和后端沟通会很顺畅。结果现实狠狠打脸。

前端用 Axios 发请求，后端用 Spring Boot 返回 JSON，看似完美。但问题出在跨域和认证上。

开发时，前端跑在 localhost:3000，后端在 localhost:8080。后端同事说：“你配个 Nginx 反代不就行了？” 我说：“那每个前端都得装Nginx？太重了。”

最后我们在 Webpack Dev Server 里加了 proxy：

// webpack.config.js (dev)
devServer: {
  proxy: {
    '/api': {
      target: 'http://localhost:8080',
      changeOrigin: true,
      pathRewrite: { '^/api': '' }
    }
  }
}

上线后，Nginx 统一反代，问题解决。但更大的坑在鉴权。

后端用 JWT，但把 token 放在响应头 X-Auth-Token 里。前端需要手动读取并存到 localStorage。可某次安全审计要求“禁止 localStorage 存 token”，必须用 HttpOnly Cookie。

我去找后端商量，对方一脸懵：“我们Java这边都是这么干的啊。” 最后磨了三天，后端才愿意改接口，把 token 写进 Set-Cookie。

感悟：前后端联调，本质是“协议谈判”。

---

部署流程：从“手动 FTP”到 GitOps

最开始，前端部署靠运维手动拖文件到服务器。有一次，我改了个CSS，但忘了清 CDN 缓存，结果用户看到的还是旧样式。产品经理（现在的我）在群里咆哮：“为什么按钮还是蓝色的？！”

痛定思痛，我决定上自动化。

我们用 GitLab CI + Docker + Kubernetes（K8s），实现从 push 到上线的全自动。

流程如下：

1. 开发推代码到 feature/xxx 分支
2. MR 合并到 develop，触发 CI：lint → test → build
3. 构建成功后，打 Docker 镜像，推到 Harbor
4. 运维审批后，自动部署到 K8s 测试环境
5. 验收通过，合并到 main，自动部署到生产

关键在于 Dockerfile 和 K8s Deployment 的配合。

# Dockerfile
FROM nginx:alpine
COPY build/ /usr/share/nginx/html
COPY nginx.conf /etc/nginx/nginx.conf
EXPOSE 80

# k8s/deployment.yaml
apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: frontend
        image: harbor.mycompany.com/frontend:latest
        ports:
        - containerPort: 80

但第一次上线时，K8s Pod 一直 CrashLoopBackOff。查日志发现：Nginx 启动太快，build 目录还没挂载完。加了个 initContainer 等待文件就绪，才搞定。

---

性能优化：别让“加载中”成为用户噩梦

工程化不只是流程，更是体验。我们用 Lighthouse 扫描，初始得分只有 45 —— 主要卡在“首次内容绘制（FCP）”和“最大内容绘制（LCP）”。

原因很简单：一个 vendor.js 2.8MB，首屏加载要 8 秒。

优化策略：

1. 代码分割：用 React.lazy + Suspense 按路由拆包
2. 预加载：关键资源用 <link rel="preload">
3. CDN + Gzip：Nginx 开启 gzip，静态资源走 CDN
4. 图片优化：WebP 格式 + lazy load

// 路由懒加载
const Home = React.lazy(() => import('./pages/Home'));
const App = () => (
  <Suspense fallback={<Spinner />}>
    <Routes>
      <Route path="/" element={<Home />} />
    </Routes>
  </Suspense>
);

优化后，Lighthouse 分数提到 85+，首屏加载压到 1.8 秒。用户反馈：“终于不用看着转圈圈发呆了。”

---

踩坑总结：一张表看透关键决策

问题领域	错误做法	正确做法	血泪指数
构建工具	盲目追新（Vite不兼容IE）	开发用Vite，生产用Webpack+Babel	⭐⭐⭐⭐
项目结构	强推Monorepo	独立仓库 + 私有npm包	⭐⭐⭐
跨域联调	让前端自己配Nginx	Webpack devServer proxy	⭐⭐
部署方式	手动FTP上传	GitLab CI + Docker + K8s	⭐⭐⭐⭐⭐
性能优化	一个bundle打天下	路由懒加载 + CDN + 图片优化	⭐⭐⭐

---

写在最后：从PM到工程师的思维转变

说实话，从产品经理转技术，最大的挑战不是写代码，而是从“我要什么”变成“怎么实现”。

以前我只会说：“这个功能明天必须上线！” 现在我会问：“这个需求的技术边界在哪？有没有兼容性风险？”

在成都这座慢节奏的城市，我反而更珍惜高效、稳定的工程体系。它让我们不必在 deadline 前夜疯狂加班，不必因为一个 console.log 忘删而回滚线上。

前端工程化，表面是工具链和流程，内核其实是对确定性的追求。当你知道每次 push 代码会发生什么，当你的构建不会随机失败，当你的部署不再靠“玄学”，你才真正拥有了掌控感。

现在，我依然用 Vim 写代码，依然在茶馆里边喝盖碗茶边 review PR。但我知道，那些曾经让我头疼的 Webpack 配置、K8s yaml、Babel 插件，已经成了我新身份的一部分。

对了，上周五晚上，我又被叫去救火——某个第三方 SDK 导致内存泄漏。但这次，我没想砸电脑，而是淡定地打开 Chrome DevTools，Profile 一把，定位问题，提 PR。

因为我知道，这就是工程师的日常。

而我，乐在其中。