从外包狗到React新手：我的第一个应用踩坑实录
上周五晚上十一点，我还在工位上跟一个祖传jQuery项目死磕。产品经理突然在钉钉上@我：“这个页面下周上线，加个实时数据看板，用React写。” 我差点一口老血喷在机械键盘上——咱公司后端用的是Springboot，前端还是JSP混着Bootstrap，现在突然要上React？而且只给五天？
但没办法啊，谁让咱是外包公司的“万金油”呢。干了四年，从PHP改Java再切到Node，现在又得捡起React。好在我平时靠ChatGPT和Claude续命，刷LeetCode准备跳槽之余，也顺手把React文档啃了几遍。既然躲不过，那就硬刚吧。
为什么非得用React？
其实我心里清楚：客户那边新招了个“技术总监”，开口闭口就是“前后端分离”、“微前端架构”。我们原来的JSP页面直接调Springboot接口，虽然糙但快。现在非要拆成纯前端项目，后端只提供API——典型的“综合”型需求：既要快，又要新，还得显得高大上。
行吧，反正我简历上也缺个React项目。搞定了说不定跳槽能多要两千块。
环境搭建：别信网上那些“一行命令搞定”的鬼话
网上教程都说 npx create-react-app my-app 就完事了。可我在公司内网环境下跑这命令，npm源被墙得妈都不认，折腾半小时才换到淘宝镜像。
更坑的是，create-react-app 默认用Webpack 5 + Babel 7，结果我本地Node版本是14（运维死活不给升），各种兼容报错。最后还是用Vite重来，速度快得飞起：
npm create vite@latest my-react-app -- --template react
cd my-react-app
npm install
npm run dev
三秒启动开发服务器，热更新丝滑。那一刻我悟了：外包人的时间就是金钱，谁还等Webpack打包两分钟？
第一个组件：别一上来就搞Hooks全家桶
很多新手（包括我）一开始就想秀技术，useEffect、useContext、useReducer全往上堆。结果呢？代码写得自己都看不懂，改个bug改到凌晨三点。
我的建议：先写个最简单的函数组件，连状态都不用。
// src/components/HelloWorld.jsx
export default function HelloWorld() {
return <h1>外包人，React初体验</h1>;
}
然后在 App.jsx 里引入：
import HelloWorld from './components/HelloWorld';
function App() {
return (
<div className="App">
<HelloWorld />
</div>
);
}
跑起来，看到页面显示文字——搞定！这时候千万别急着加功能。先确认你的开发环境没问题，ESLint、Prettier配置好，Git hooks跑起来。这些基建工作在后期能省你无数时间。
调后端接口：跨域？代理走起！
我们的Springboot后端跑在 localhost:8080，React开发服务器是 localhost:5173，直接fetch肯定跨域。网上一堆教程让你改后端加CORS，但在外包项目里，后端大哥根本懒得动代码——“你们前端自己解决”。
行，那我们就用Vite的代理配置，vite.config.js 加上：
export default defineConfig({
server: {
proxy: {
'/api': {
target: 'http://localhost:8080',
changeOrigin: true,
rewrite: (path) => path.replace(/^\/api/, '')
}
}
}
})
这样前端请求 /api/users，实际会转发到 http://localhost:8080/users，完美避开跨域。而且上线时Nginx配一下反向代理就行，不用改任何前端代码。
状态管理：别被Redux吓到
我第一次看到Redux的样板代码，真的想砸电脑。但现在React自带的 useState + useContext 已经能应付90%的场景。除非你要做大型中后台系统，否则别一上来就上Zustand或Redux Toolkit。
举个简单例子：从Springboot拿用户列表并展示。
// src/App.jsx
import { useState, useEffect } from 'react';
function App() {
const [users, setUsers] = useState([]);
const [loading, setLoading] = useState(true);
useEffect(() => {
fetch('/api/users')
.then(res => res.json())
.then(data => {
setUsers(data);
setLoading(false);
})
.catch(err => {
console.error('接口挂了！', err);
setLoading(false);
});
}, []);
if (loading) return <div>加载中...</div>;
return (
<ul>
{users.map(user => (
<li key={user.id}>{user.name}</li>
))}
</ul>
);
}
就这么简单。别整那些花里胡哨的。开发心得：能用原生Hooks解决的，就别引入第三方库。每多一个依赖，未来就多一个升级的坑。
样式怎么写？CSS Modules香得很
以前在jQuery时代，全局CSS冲突到怀疑人生。现在React组件化，我强烈推荐用CSS Modules：
/* src/components/UserList.module.css */
.userItem {
padding: 12px;
border-bottom: 1px solid #eee;
transition: background 0.2s;
}
.userItem:hover {
background: #f5f5f5;
}
// UserList.jsx
import styles from './UserList.module.css';
export default function UserList({ users }) {
return (
<ul>
{users.map(user => (
<li className={styles.userItem} key={user.id}>
{user.name}
</li>
))}
</ul>
);
}
样式自动局部作用域，类名还会被哈希化，完全不用担心污染。而且支持Sass、Less，按需启用就行。
浏览器兼容性？外包项目真不用太纠结
我知道有些同学会问IE11怎么办。兄弟，醒醒！2024年了，连政府项目都不要求IE了。我们最近一个银行项目，明确写了“仅支持Chrome 80+”。所以放心用现代语法，Vite默认的Babel配置已经够用。
但如果客户真提了兼容需求……建议直接加个提示页：“请使用Chrome访问”，然后报价翻倍。
调试技巧：React DevTools是神
装个浏览器插件 React Developer Tools，组件树、props、state 一目了然。比console.log高效十倍。特别是排查“为什么这个组件没更新”时，直接看props有没有变，省下无数debug时间。
另外，Vite的HMR（热模块替换）是真的快。改一行JSX，页面瞬间刷新，状态还不丢。对比以前Webpack的慢吞吞，简直是天堂。
上线部署：别忘了静态资源路径
本地跑得好好的，build完扔到Nginx上，图片404、路由404……这种事我见多了。
关键两点：
vite.config.js里设置base: './'（如果放子目录，改成对应路径）- Nginx配置要支持HTML5 History模式：
location / {
try_files $uri $uri/ /index.html;
}
不然用户直接访问 /users 页面会404。
总结：外包人的React入门心法
这次从零搭React应用，虽然只用了三天（剩下两天在改UI细节），但收获不小。开发心得如下：
| 踩坑点 | 正确姿势 |
|---|---|
| 盲目用create-react-app | 优先考虑Vite，快！ |
| 一上来就搞复杂状态管理 | 先用useState + useContext |
| 忽略代理配置 | 开发阶段必须配proxy |
| 全局CSS乱写 | 强制用CSS Modules |
| 不测上线流程 | build后本地serve预览 |
说到底，React的核心不是语法，而是组件化思维。把页面拆成小零件，每个零件只关心自己的输入输出，后端（比如我们的Springboot）只管提供干净的API。前后端各司其职，这才是“综合”解决方案该有的样子。
现在这个项目已经上线了。虽然界面丑得要死（UI设计师被砍掉了），但至少技术栈看起来“现代化”了。领导很满意，说下次投标可以吹“全栈React+Springboot架构”。
而我？继续刷我的算法题，准备跳槽。毕竟，在外包公司，学新技术从来不是为了项目，而是为了下一份工资。
评论 0