从零开始构建一个现代化前端项目：一个考公程序员的深夜复盘
去年十月的一个周五晚上，11点27分，我瘫在杭州未来科技城出租屋的破沙发上，手里捏着半瓶冰啤酒，电脑屏幕还亮着——一个 React 项目跑不起来，满屏红字报错，Module not found: Can't resolve 'react-router-dom'。老婆在隔壁房间轻声说：“明天还要早起刷行测题，别熬太晚。”我嗯了一声，心里却像被塞了团湿棉花——又累又闷。
那时候，我白天在一家做 Java 后端的 SaaS 公司敲代码，月薪 18k，房租 3500，房贷 4200。表面上是个“稳定”的程序员，实际上每天都在焦虑：35 岁危机、技术迭代、杭州房价……更别提我偷偷报名了省考，目标是进体制内，图个安稳。可现实是，一边要刷《申论》和数量关系，一边还得维护公司那套十年前的 jQuery + JSP 架构——没错，我们后端用 Java，但前端？还是 <script> 标签里写 onclick 的时代。
直到上个月，公司突然决定重构一个核心客户后台，老板拍板：“这次必须用 React，搞成现代化前端！”我作为唯一有点 React 经验的人（其实也就业余做过两个小 demo），被推上了“前端负责人”的位置。那一刻，我既兴奋又害怕——兴奋的是终于能用新技术了，害怕的是：我真会搭一个“现代化”的项目吗？
从 npm init 开始，我差点翻车
说实话，刚开始我信心满满。不就是 create-react-app 一把梭吗？但很快现实就打了脸。
第一个坑：项目结构怎么组织？
我照搬了网上教程，把所有组件扔进 src/components，结果两周后连自己都找不到 UserList.jsx 到底在哪个子文件夹。后来我参考了 Dan Abramov 的建议，按“功能模块”而非“文件类型”划分目录：
src/
├── features/
│ ├── user/
│ │ ├── components/
│ │ ├── hooks/
│ │ ├── services/
│ │ └── index.js
│ └── dashboard/
├── shared/
│ ├── ui/ // 通用按钮、弹窗等
│ └── utils/
└── App.js
这种“feature-first”结构，让新同事接手时直呼“清晰”，连 HR 都在周会上夸我“有工程思维”——虽然她可能根本不知道我在说什么。
第二个坑：和 Java 后端对接，跨域炸了
我们后端是 Spring Boot，本地开发时前端跑在 localhost:3000，后端在 localhost:8080。每次调接口，浏览器直接给我一个 CORS error。我一度想放弃，改用 Postman 调试——但那样效率太低。
后来我学会了在 package.json 里加一行：
"proxy": "http://localhost:8080"
瞬间搞定。不过这只是开发环境方案。上线时，我们靠 Nginx 反向代理统一入口，彻底解决跨域问题。这让我深刻体会到：前端不是孤岛，必须和后端协同设计。
技术选型：不是越新越好，而是越稳越好
很多人一上来就问：“用 Next.js 还是 Remix？Vite 还是 Webpack？”
但作为一个背着房贷、准备考公的人，我深知：稳定压倒一切。
我最终选择了：
- React 18 + TypeScript：类型安全能避免很多低级错误，尤其在我熬夜写代码时；
- React Router v6：路由配置更简洁，嵌套路由逻辑清晰；
- Axios + 自定义 hooks：封装 API 调用，避免重复代码；
- Tailwind CSS：不用写 CSS，快速出 UI，适合我这种审美一般的程序员；
- Jest + React Testing Library：虽然考公没时间写测试，但关键组件还是得覆盖，不然上线就崩。
最让我自豪的是，我写了一个 useApi hook，自动处理 loading、error、data 状态：
const { data, loading, error } = useApi<User[]>(() => fetchUsers());
后端同事看了直说：“你们前端现在也玩泛型了？牛啊！”——其实我只是不想再被产品经理半夜 call 起来修 bug 了。
求职视角：这段经历意外成了我的加分项
今年三月，我参加了一次公务员面试后的“技术岗调剂”（别笑，有些事业单位也有技术岗）。面试官看到我简历里写着“主导 React 项目重构”，眼睛一亮。
他问：“你说的‘现代化’，具体指什么？”
我没背八股文，而是讲了那个周五晚上的崩溃场景，讲了如何从混乱到有序，如何和 Java 后端对齐接口规范，甚至讲了我们如何用 Git 提交信息规范（比如 feat(user): add delete button）让 Code Review 更高效。
最后他说：“你不是在堆技术，而是在解决问题。我们需要这样的人。”
虽然最后我没去那个岗位（因为笔试分数不够），但这次经历让我明白：技术分享的价值，不在于炫技，而在于传递思考过程。
考公与写代码，真的冲突吗？
很多人问我：“你一个程序员，干嘛非要去考公？”
上周日，我和老婆在小区楼下散步，她突然说：“其实你写代码的时候，眼睛是有光的。”
我愣了一下，想起上周五晚上，我居然主动加班到凌晨两点，就为了优化一个表格的渲染性能——那一刻，我忘了房贷，忘了行测，忘了 35 岁。
或许，考公不是为了逃离技术，而是为了寻找一种可持续的生活方式。我不想像某些大厂同事那样，35 岁就被“优化”，然后被迫转行开滴滴。我想在体制内，依然能写代码，做点小工具，帮单位提效——哪怕只是用 Excel VBA。
而这段从零搭建 React 项目的过程，恰恰证明了：无论在哪里，解决问题的能力才是核心。
给同样在挣扎的你几点建议
- 别怕从零开始。我第一次跑
npm install时，依赖装了 20 分钟，电脑风扇狂转。但只要迈出第一步，后面都是路。 - 技术为业务服务。别为了用 Redux Toolkit 而用，如果状态简单，useState 足够。我们项目至今没用 Redux，全靠 Context + useReducer，跑得飞快。
- 文档比代码重要。我在项目根目录写了
DEVELOPMENT.md，记录了本地启动、联调、部署全流程。新来的实习生半天就上手了，老板夸我“有传承意识”。 - 保持学习，但别焦虑。我每天只学 30 分钟，可能是看 React 官方文档，也可能是刷一道 LeetCode。积少成多，总比什么都不做强。
写在最后
此刻是凌晨 12 点，我又坐在书桌前。电脑开着 VS Code，终端里 npm run dev 正常运行；旁边摊着《行测 5000 题》，咖啡凉了。
我知道，无论是考公上岸，还是继续做程序员，前方都不会轻松。但至少，我学会了在混乱中建立秩序——不管是用 React 搭建项目，还是用计划表安排生活。
前几天，老婆笑着说：“你最近脾气好了，是不是因为项目顺了？”
我摇摇头：“是因为我知道，不管结果如何，我都在变得更好。”
所以，如果你也在杭州，也在还房贷，也在技术与生活的夹缝中挣扎——别怕。从 npx create-react-app 开始，或者从今天的第一道行测题开始，每一步，都算数。
共勉。
评论 0