React入门教程：从安装到第一个应用 —— 一个被双11逼出来的前端老油条的实战手记
坐标深圳，阿里P7前端工程师。经历过三次双11大促的“洗礼”，头发越来越少，代码越写越稳（大概？）。今天不聊性能优化，也不吐槽产品经理半夜改需求，就带大家从零跑通第一个React应用——因为上周五晚上，我新来的实习生问了我一句：“哥，这React到底怎么装啊？”
说实话，听到这句话的时候，我差点笑出声。但转念一想——我自己第一次接触React时，不也是对着create-react-app一脸懵，以为要手动配Webpack、Babel、ESLint，结果折腾到凌晨三点，连个Hello World都没跑起来？最后还是靠隔壁腾讯系兄弟给的一行命令救了我。
所以今天这篇文章，不是那种“先讲JSX再讲组件生命周期”的教科书式教程。我要用实战经验的方式，带你从安装到写出第一个能跑、能交互、还能部署的React小应用。顺便夹点私货：聊聊我在大促项目里踩过的坑、用过的工具，以及为什么我们前端总得跟后端撕来撕去（别急，是友好的技术协作 😏）。
背景：为什么我又在教人装React？
去年双11前两周，团队接了个紧急需求：给商家后台加个“实时库存预警看板”。时间紧、任务重，领导拍板：“用React重写，性能好、组件化强，还能复用之前的Hook。”
问题来了——新来的两个校招生，只会Vue，连Node.js都还没装全。那天下午三点，会议室里一片哀嚎：“npm install 报错！”、“localhost:3000 打不开！”、“这个import语法为啥报错？”
我当时真的想砸键盘。但转头一看窗外深圳湾的夕阳，深吸一口气：算了，谁还不是从npx create-react-app my-app开始的呢？
于是就有了这篇“血泪史”整理版教程。
第一步：环境准备 —— 别让工具链劝退你
很多新手卡在第一步：装Node.js。别慌，我建议直接上Node.js官网下 LTS版本（目前是20.x），别整那些奇奇怪怪的nvm多版本管理——除非你像我一样，在Mac上同时跑着5个不同Node版本测兼容性（是的，我们组有个“复古浏览器支持清单”，IE11已死，但某些政府系统还在用Edge Legacy……）。
装完之后，终端里敲：
node -v
npm -v
看到版本号就说明OK了。这时候千万别急着npm install -g create-react-app！这是2024年最大的误区之一。
为什么？因为官方早就推荐用 npx 了，它会自动拉取最新版脚手架，避免全局污染。你想想，要是你全局装了个旧版CRA，三个月后新项目用不了TypeScript模板，那不是给自己挖坑？
所以正确姿势是：
npx create-react-app stock-alert-dashboard --template typescript
小贴士：我习惯加上
--template typescript，毕竟在阿里系，TS已经是标配了。虽然一开始写得慢点，但后期重构和多人协作时，类型安全真的能救命——尤其当你半夜被叫起来修线上Bug时。
等个两三分钟（取决于你家宽带，深圳科技园这边晚高峰GitHub抽风是常态），目录结构就出来了。进目录，npm start，浏览器自动弹出 http://localhost:3000，React logo缓缓旋转——那一刻，真的有初恋的感觉。
第二步：第一个组件 —— 别光写Hello World，来点真实的
很多人教程到这里就结束了。但咱们要实战，所以直接上需求：做一个“库存预警卡片”，显示商品名称、当前库存、预警阈值，并且当库存低于阈值时，文字变红色。
先别急着写代码。打开 src/App.tsx，删掉所有默认内容（对，包括那个旋转的React logo，虽然好看但占包体积）。
// src/App.tsx
import React, { useState } from 'react';
const StockAlertCard = () => {
const [stock, setStock] = useState(8);
const threshold = 10;
return (
<div style={{ padding: '20px', border: '1px solid #eee', borderRadius: '8px' }}>
<h2>【iPhone 15 Pro】库存预警</h2>
<p>当前库存: <span style={{ color: stock < threshold ? 'red' : 'black' }}>{stock}</span></p>
<p>预警阈值: {threshold}</p>
<button onClick={() => setStock(prev => prev - 1)}>手动扣减库存</button>
</div>
);
};
function App() {
return (
<div className="App">
<StockAlertCard />
</div>
);
}
export default App;
保存，热更新立马生效。点击按钮，数字减少，低于10就变红——搞定！
但等等，这太假了！真实场景中，库存数据肯定来自后端接口。所以下一步，我们要模拟一次API调用。
第三步：对接后端 —— 别再mock到天荒地老
在实际项目中，前端和后端经常因为接口格式吵架。比如后端返回 { data: { stock: 8 } }，你却按 { stock: 8 } 解构，结果页面白屏。双11期间这种事我见太多了——测试同学凌晨两点在钉钉@你：“线上库存没显示！”
为了避免这种情况，我建议早期就和后端对齐接口文档。但现在只是本地开发，我们可以用 msw（Mock Service Worker）来拦截请求，在浏览器层面 mock API，而不是在代码里硬编码假数据。
安装：
npm install msw --save-dev
创建 src/mocks/handlers.ts：
import { rest } from 'msw';
export const handlers = [
rest.get('/api/stock', (req, res, ctx) => {
return res(
ctx.status(200),
ctx.json({
data: {
productName: 'iPhone 15 Pro',
stock: 8,
threshold: 10
}
})
);
}),
];
再创建 src/mocks/browser.ts：
import { setupWorker } from 'msw';
import { handlers } from './handlers';
export const worker = setupWorker(...handlers);
最后在 src/index.tsx 顶部加入：
// src/index.tsx
import React from 'react';
import ReactDOM from 'react-dom/client';
import App from './App';
import { worker } from './mocks/browser';
// 只在开发环境启用mock
if (process.env.NODE_ENV === 'development') {
worker.start();
}
const root = ReactDOM.createRoot(
document.getElementById('root') as HTMLElement
);
root.render(<App />);
现在，把组件改成从接口获取数据：
// src/App.tsx
import React, { useState, useEffect } from 'react';
const StockAlertCard = () => {
const [data, setData] = useState<{ productName: string; stock: number; threshold: number } | null>(null);
useEffect(() => {
fetch('/api/stock')
.then(res => res.json())
.then(result => setData(result.data));
}, []);
if (!data) return <div>加载中...</div>;
const { productName, stock, threshold } = data;
return (
<div style={{ padding: '20px', border: '1px solid #eee', borderRadius: '8px' }}>
<h2>【{productName}】库存预警</h2>
<p>当前库存: <span style={{ color: stock < threshold ? 'red' : 'black' }}>{stock}</span></p>
<p>预警阈值: {threshold}</p>
</div>
);
};
刷新页面，数据正常加载。关键点在于：这套mock机制完全模拟真实网络请求，你在DevTools的Network面板里能看到 /api/stock 请求，状态码200，响应体清晰可见。这样，等后端接口ready后，你只需要删掉mock代码，URL换成真实地址就行——无缝切换。
第四步：调试与优化 —— 别等到上线才看性能
在深圳做前端，老板第一句永远是：“首屏要快，用户流失率高！” 所以从第一天起，就得关注性能。
推荐两个工具：
- React DevTools：Chrome插件，能看组件层级、props变化、Hook状态。双11期间我靠它定位了一个无限渲染的Bug——某个useEffect没加依赖数组，导致每秒重发10次请求。
- Lighthouse：内置在Chrome DevTools里，跑一次就能看到Performance分数。我的目标是>90，否则会被性能团队diss。
另外，别忘了开启生产构建测试：
npm run build
npx serve -s build
访问 http://localhost:3000，看看真实打包后的效果。你会发现，开发环境的Warning没了，JS文件压缩了，而且没有Source Map（除非你特意配置）。这才是用户看到的样子。
一些血泪总结
| 阶段 | 新手常见误区 | 我的实战建议 |
|---|---|---|
| 环境搭建 | 全局安装CRA | 用 npx，避免版本冲突 |
| 组件开发 | 直接写逻辑，不分层 | 小功能也拆成独立组件，方便复用 |
| 数据请求 | 在组件里直接fetch | 封装API层，配合mock |
| 调试 | console.log 到处飞 | 用React DevTools + Network面板 |
| 部署 | 直接传build文件夹 | 用CI/CD自动化，比如GitHub Actions |
最后：React不是终点，而是起点
写到这里，窗外又是深圳的深夜。想起去年双11零点，监控大盘突然报警，库存组件渲染超时——最后发现是某个新人用了Array.map嵌套三层，没加key，导致Diff算法爆炸。
React本身不难，难的是在复杂业务中保持代码的可维护性和性能。但只要你从第一个应用就养成好习惯：用TS、mock接口、关注性能、善用工具，后面的日子会轻松很多。
如果你看完这篇教程，成功跑起了自己的React应用——恭喜你，已经超过了80%只停留在“收藏夹吃灰”的同行。
至于我？明天还得和后端对齐新的库存推送WebSocket协议。产品经理刚在群里说：“能不能加个动画？库存变红的时候抖一下？”……
唉，前端的命，都是产品经理给的（狗头保命）。
技术分享不易，点赞关注不迷路。我是那个在双11凌晨三点还在调CSS的阿里P7前端，坐标深圳，Mac党，Windows只用来测兼容性。下次聊：《如何用React.memo和useCallback干掉双11性能瓶颈》。
评论 0