关于乐高项目避坑：3个致命错误与完整示例详解
刚学会几行代码，觉得语法都背熟了，结果一动手搭项目就卡壳？别慌，我当年也这样。很多新手在【关于乐高】这类组件化开发场景中，最容易陷入“看着能跑，一拆就崩”的怪圈。这篇文章不整虚的，直接给你一套【完整示例】，专门针对那些让你头秃的常见坑，从现象到修复，一步步带你把项目理顺。
坑一：组件状态同步不及时，界面“假死”
现象：为什么改了数据，UI不动？
你是不是遇到过这种情况：在父组件里修改了某个属性，子组件理应更新，但界面就是纹丝不动？或者点击按钮后，数据明明在控制台打印出来了，但页面上的列表还是旧的。这时候你通常会怀疑是不是数据没传过去，反复检查 props，发现值确实变了，但 UI 就是“装傻”。这种【关于乐高】组件库中常见的状态同步延迟，往往不是数据流的问题，而是生命周期钩子使用不当导致的。
根本原因：混淆了渲染与更新机制
很多教程会告诉你，“数据驱动视图”，这话没错，但漏了关键一环：渲染是同步的，但某些更新是异步批处理的。在 React 或类似框架中，当你在事件处理函数中更新 state 时，框架为了性能会进行批量更新。如果你紧接着在同一个执行栈里去读取或依赖这个 state 的变化来触发其他逻辑，拿到的还是旧值。更隐蔽的坑在于，如果你直接修改了 props 传递下来的对象引用，而没有触发重新渲染，子组件根本不知道父组件的数据变了。Stack Overflow 上有大量帖子讨论过类似的问题，核心结论是：不要直接修改 props，要传递新的引用或状态。
正确写法对比
错误写法（直接修改对象引用）：
// 父组件 Parent.js
import React, { useState } from 'react';
import LegoChild from './LegoChild';
function Parent() {
const [config, setConfig] = useState({ theme: 'light', size: 'md' });
const handleChange = () = {
// 坑点：直接修改对象属性，没有产生新引用
config.theme = 'dark';
config.size = 'lg';
// 这里没有调用 setConfig，React 检测不到变化
};
return (
div
button onClick={handleChange}切换主题/button
LegoChild config={config} /
/div
);
}
正确写法（创建新对象并触发更新）：
// 父组件 Parent.js
import React, { useState } from 'react';
import LegoChild from './LegoChild';
function Parent() {
const [config, setConfig] = useState({ theme: 'light', size: 'md' });
const handleChange = () = {
// 正确：创建新对象，确保引用改变
const newConfig = { ...config, theme: 'dark', size: 'lg' };
setConfig(newConfig);
};
return (
div
button onClick={handleChange}切换主题/button
LegoChild config={config} /
/div
);
}
复现与修复代码
为了验证这个问题，我们可以写一个简单的测试用例。在 LegoChild 组件中，添加一个 useEffect 来监听 config 的变化。
// 子组件 LegoChild.js
import React, { useEffect } from 'react';
function LegoChild({ config }) {
useEffect(() = {
console.log('Child updated with:', config);
}, [config]); // 依赖数组必须是引用类型
return (
div style={{ background: config.theme === 'dark' ? '#333' : '#fff', padding: config.size === 'lg' ? '20px' : '10px' }}
Current Theme: {config.theme}
/div
);
}
如果使用错误写法，点击按钮后，控制台不会打印任何日志，因为 config 的引用没变，useEffect 不会重新执行。使用正确写法后，每次点击都会产生新的对象引用，触发子组件的重渲染，界面瞬间响应。
规避建议
永远不要直接修改 Props：这是铁律。所有对数据的修改，必须通过 state 的 setter 函数，并传入新值。
合理使用 useMemo：如果传递给子组件的对象计算成本很高，使用 useMemo 缓存，但注意依赖项的准确性。
调试技巧：在控制台打印对象的 Object.keys 或引用地址，确认是否生成了新引用。
坑二：异步数据加载导致组件崩溃
现象：页面白屏或报错“Cannot read property of undefined”
另一个高频坑是异步数据加载。当你从 API 获取【关于乐高】组件所需的配置信息时，数据是异步返回的。如果在数据还没回来之前，你就在渲染函数里直接访问 data.items.map(...)，一旦 data 是 undefined，整个组件就会崩溃，页面白屏。这种错误在 Stack Overflow 上被称为“Hydration Mismatch”或“Undefined Property Access”，是新手转职为熟手时最容易掉进的陷阱。
根本原因：缺少防御性编程与加载状态管理
很多初学者只关心“数据来了怎么渲染”，却忽略了“数据没来怎么办”。JavaScript 是单线程的，但网络请求是异步的。如果没有明确的状态管理（如 loading, error, data 三态），组件在数据未就绪时就会处于“未知”状态。此外，如果组件在数据加载完成前被卸载（比如用户快速切换页面），而回调函数仍在执行，尝试更新已卸载组件的 state，也会引发警告甚至错误。
正确写法对比
错误写法（无加载状态，直接渲染）：
import React, { useState, useEffect } from 'react';
function LegoDataLoader() {
const [data, setData] = useState(null);
useEffect(() = {
fetch('/api/lego-config')
.then(res = res.json())
.then(result = setData(result));
}, []);
// 坑点：data 初始为 null，直接访问 .items 会报错
return (
ul
{data.items.map(item = (
li key={item.id}{item.name}/li
))}
/ul
);
}
正确写法（三态管理 + 可选链操作符）：
import React, { useState, useEffect } from 'react';
function LegoDataLoader() {
const [data, setData] = useState(null);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);
useEffect(() = {
let isMounted = true; // 防止组件卸载后更新 state
const fetchData = async () = {
try {
const res = await fetch('/api/lego-config');
const result = await res.json();
if (isMounted) {
setData(result);
setLoading(false);
}
} catch (err) {
if (isMounted) {
setError(err.message);
setLoading(false);
}
}
};
fetchData();
return () = {
isMounted = false; // 清理函数
};
}, []);
if (loading) return divLoading.../div;
if (error) return divError: {error}/div;
if (!data) return null;
return (
ul
{/* 使用可选链操作符，双重保险 */}
{(data.items || []).map(item = (
li key={item.id}{item.name}/li
))}
/ul
);
}
复现与修复代码
要复现这个坑，只需在 API 响应中故意延迟 2 秒，并在 data 为 null 时运行错误代码。你会看到控制台抛出 TypeError: Cannot read properties of null (reading 'items')。使用正确写法后，页面会先显示“Loading...”，数据到达后无缝切换为列表，若接口报错则显示错误信息，用户体验平滑且健壮。
规避建议
始终初始化 State 为合理默认值：如 [] 而非 null，或使用 null 但配合条件渲染。
使用可选链 ?.：data?.items?.map 是现代 JS 的标配，能有效防止深层属性访问崩溃。
处理组件卸载：在 useEffect 返回清理函数，防止内存泄漏和警告。
统一错误处理：封装 API 请求函数，统一捕获错误，避免每个组件重复写 try-catch。
坑三：样式污染与全局变量覆盖
现象：为什么我的乐高组件在别的页面变样了？
【关于乐高】组件库通常强调“可复用”，但样式隔离往往是薄弱环节。你可能会发现，在一个页面里组件样式正常，但放到另一个页面，字体大小、颜色、边距全乱了。或者，你修改了全局 CSS 变量，结果所有乐高组件的默认样式都被覆盖，导致视觉混乱。这种“样式污染”是 CSS 作用域问题在组件化架构下的典型体现。
根本原因：CSS 全局作用域与组件隔离缺失
传统 CSS 是全局的，选择器会匹配页面中所有符合条件的元素。如果乐高组件内部使用了类名 .card，而页面其他部分也有 .card，两者就会互相干扰。虽然 CSS Modules 或 Styled Components 可以解决部分问题，但如果【关于乐高】组件库本身没有做好命名空间隔离，或者开发者在全局样式中覆盖了组件的内部类名，问题依然会发生。此外，CSS 变量的继承机制容易被滥用，导致局部修改影响全局。
正确写法对比
错误写法（全局类名 + 全局变量覆盖）：
/* global.css */
:root {
--primary-color: #007bff;
}
/* 全局覆盖，影响所有使用 .card 的组件 */
.card {
border-radius: 0 !important;
box-shadow: none !important;
}
// LegoCard.js
function LegoCard() {
return (
div className=card
h3标题/h3
p内容/p
/div
);
}
正确写法（CSS Modules + 局部作用域变量）：
/* LegoCard.module.css */
.card {
border-radius: 8px;
box-shadow: 0 2px 4px rgba(0,0,0,0.1);
padding: 16px;
/* 使用局部变量，避免被全局覆盖 */
--card-bg: #fff;
background-color: var(--card-bg);
}
// LegoCard.js
import styles from './LegoCard.module.css';
function LegoCard() {
return (
div className={styles.card}
h3标题/h3
p内容/p
/div
);
}
复现与修复代码
复现方法：在项目中同时引入两个不同库的组件，它们都使用了 .card 类名。观察其中一个组件的样式是否被另一个库的全局样式覆盖。使用 CSS Modules 后，类名会被哈希化（如 LegoCard_card_12345），彻底避免冲突。同时，将 CSS 变量定义在组件内部或局部作用域，确保不被全局 :root 中的变量意外覆盖。
规避建议
强制使用 CSS Modules 或 Scoped CSS：在团队规范中禁止直接使用全局类名。
BEM 命名法：如果无法使用 CSS Modules，严格遵循 Block-Element-Modifier 命名，如 lego-card__title，降低冲突概率。
避免 !important：这是样式调试的最后一招，用多了会让维护变成噩梦。
设计令牌（Design Tokens）：统一管理颜色、间距等变量，通过 JSON 或 JS 对象注入，而非依赖 CSS 变量的继承。
坑四：依赖版本冲突与幽灵依赖
现象：为什么本地能跑，部署就挂？
这是最隐蔽也最致命的坑。你在本地开发时，【关于乐高】组件库版本是 2.1.0，运行正常。但部署到测试环境后，突然报错“Module not found”或“Function is not defined”。检查后发现，生产环境的 node_modules 中，乐高库被提升到了 3.0.0，而该版本删除了你正在使用的某个 API。这种“幽灵依赖”问题，往往源于包管理器的嵌套依赖解析机制。
根本原因：Node 模块解析算法与版本锁定缺失
Node.js 的模块解析算法会向上查找 node_modules。如果多个包依赖同一库的不同版本，NPM 可能会将主版本提升到顶层，而子版本保留在嵌套目录中。如果你的代码直接引用了顶层的库，而实际运行时加载的是嵌套的旧版本（或反之），就会出现版本不一致。此外，package.json 中如果使用了 ^ 或 ~ 范围符，不同时间安装可能得到不同版本，导致环境差异。
正确写法对比
错误写法（未锁定版本，依赖提升）：
// package.json
{
dependencies: {
lego-ui: ^2.0.0,
my-lib: 1.0.0
}
}
假设 my-lib 内部依赖 lego-ui@3.0.0，NPM 可能将 lego-ui@3.0.0 提升到顶层，覆盖你的 ^2.0.0。
正确写法（精确版本 + package-lock.json 提交）：
// package.json
{
dependencies: {
lego-ui: 2.1.0,
my-lib: 1.0.0
}
}
并确保 package-lock.json 或 yarn.lock 被提交到版本控制系统。
复现与修复代码
复现方法：在本地删除 node_modules 和 package-lock.json，重新执行 npm install。对比两次安装后的 lego-ui 版本。使用精确版本并锁定 package-lock.json 后，每次安装都会得到完全相同的依赖树，消除环境差异。
规避建议
提交 Lock 文件：package-lock.json 是项目的“快照”，必须提交到 Git。
使用精确版本：对于核心依赖，尽量避免 ^ 和 ~，指定精确版本号。
定期审计依赖：使用 npm audit 或 yarn audit 检查已知漏洞和版本冲突。
Docker 化部署：将 node_modules 打包进 Docker 镜像，确保生产环境与开发环境完全一致。
总结与行动指南
【关于乐高】项目的稳定性，不取决于你写了多少代码，而取决于你如何管理状态、数据、样式和依赖。这四个坑，每一个都足以让项目在生产环境崩溃。记住，防御性编程和环境一致性是资深开发与初级开发的分水岭。
不要等到上线后才发现问题。现在就去检查你的项目：
是否有直接修改 Props 的代码？
异步数据加载是否有 loading 状态？
CSS 是否使用了模块化隔离？
package-lock.json 是否已提交？
完成这四步，你的项目稳定性至少提升 50%。
还有什么不懂的？评论区留言挨个回。 
长河君 · 2026/9/21 21:41:33 · 阅读 1.2k 关于乐高项目避坑：3个致命错误与完整示例详解
关于乐高项目避坑：3个致命错误与完整示例详解
刚学会几行代码，觉得语法都背熟了，结果一动手搭项目就卡壳？别慌，我当年也这样。很多新手在【关于乐高】这类组件化开发场景中，最容易陷入“看着能跑，一拆就崩”的怪圈。这篇文章不整虚的，直接给你一套【完整示例】，专门针对那些让你头秃的常见坑，从现象到修复，一步步带你把项目理顺。
坑一：组件状态同步不及时，界面“假死”
现象：为什么改了数据，UI不动？
你是不是遇到过这种情况：在父组件里修改了某个属性，子组件理应更新，但界面就是纹丝不动？或者点击按钮后，数据明明在控制台打印出来了，但页面上的列表还是旧的。这时候你通常会怀疑是不是数据没传过去，反复检查 props，发现值确实变了，但 UI 就是“装傻”。这种【关于乐高】组件库中常见的状态同步延迟，往往不是数据流的问题，而是生命周期钩子使用不当导致的。
根本原因：混淆了渲染与更新机制
很多教程会告诉你，“数据驱动视图”，这话没错，但漏了关键一环：渲染是同步的，但某些更新是异步批处理的。在 React 或类似框架中，当你在事件处理函数中更新 state 时，框架为了性能会进行批量更新。如果你紧接着在同一个执行栈里去读取或依赖这个 state 的变化来触发其他逻辑，拿到的还是旧值。更隐蔽的坑在于，如果你直接修改了 props 传递下来的对象引用，而没有触发重新渲染，子组件根本不知道父组件的数据变了。Stack Overflow 上有大量帖子讨论过类似的问题，核心结论是：不要直接修改 props，要传递新的引用或状态。
正确写法对比
错误写法（直接修改对象引用）：
// 父组件 Parent.js
import React, { useState } from 'react';
import LegoChild from './LegoChild';
function Parent() {
const [config, setConfig] = useState({ theme: 'light', size: 'md' });
const handleChange = () = {
// 坑点：直接修改对象属性，没有产生新引用
config.theme = 'dark';
config.size = 'lg';
// 这里没有调用 setConfig，React 检测不到变化
};
return (
div
button onClick={handleChange}切换主题/button
LegoChild config={config} /
/div
);
}
正确写法（创建新对象并触发更新）：
// 父组件 Parent.js
import React, { useState } from 'react';
import LegoChild from './LegoChild';
function Parent() {
const [config, setConfig] = useState({ theme: 'light', size: 'md' });
const handleChange = () = {
// 正确：创建新对象，确保引用改变
const newConfig = { ...config, theme: 'dark', size: 'lg' };
setConfig(newConfig);
};
return (
div
button onClick={handleChange}切换主题/button
LegoChild config={config} /
/div
);
}
复现与修复代码
为了验证这个问题，我们可以写一个简单的测试用例。在 LegoChild 组件中，添加一个 useEffect 来监听 config 的变化。
// 子组件 LegoChild.js
import React, { useEffect } from 'react';
function LegoChild({ config }) {
useEffect(() = {
console.log('Child updated with:', config);
}, [config]); // 依赖数组必须是引用类型
return (
div style={{ background: config.theme === 'dark' ? '#333' : '#fff', padding: config.size === 'lg' ? '20px' : '10px' }}
Current Theme: {config.theme}
/div
);
}
如果使用错误写法，点击按钮后，控制台不会打印任何日志，因为 config 的引用没变，useEffect 不会重新执行。使用正确写法后，每次点击都会产生新的对象引用，触发子组件的重渲染，界面瞬间响应。
规避建议
永远不要直接修改 Props：这是铁律。所有对数据的修改，必须通过 state 的 setter 函数，并传入新值。
合理使用 useMemo：如果传递给子组件的对象计算成本很高，使用 useMemo 缓存，但注意依赖项的准确性。
调试技巧：在控制台打印对象的 Object.keys 或引用地址，确认是否生成了新引用。
坑二：异步数据加载导致组件崩溃
现象：页面白屏或报错“Cannot read property of undefined”
另一个高频坑是异步数据加载。当你从 API 获取【关于乐高】组件所需的配置信息时，数据是异步返回的。如果在数据还没回来之前，你就在渲染函数里直接访问 data.items.map(...)，一旦 data 是 undefined，整个组件就会崩溃，页面白屏。这种错误在 Stack Overflow 上被称为“Hydration Mismatch”或“Undefined Property Access”，是新手转职为熟手时最容易掉进的陷阱。
根本原因：缺少防御性编程与加载状态管理
很多初学者只关心“数据来了怎么渲染”，却忽略了“数据没来怎么办”。JavaScript 是单线程的，但网络请求是异步的。如果没有明确的状态管理（如 loading, error, data 三态），组件在数据未就绪时就会处于“未知”状态。此外，如果组件在数据加载完成前被卸载（比如用户快速切换页面），而回调函数仍在执行，尝试更新已卸载组件的 state，也会引发警告甚至错误。
正确写法对比
错误写法（无加载状态，直接渲染）：
import React, { useState, useEffect } from 'react';
function LegoDataLoader() {
const [data, setData] = useState(null);
useEffect(() = {
fetch('/api/lego-config')
.then(res = res.json())
.then(result = setData(result));
}, []);
// 坑点：data 初始为 null，直接访问 .items 会报错
return (
ul
{data.items.map(item = (
li key={item.id}{item.name}/li
))}
/ul
);
}
正确写法（三态管理 + 可选链操作符）：
import React, { useState, useEffect } from 'react';
function LegoDataLoader() {
const [data, setData] = useState(null);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);
useEffect(() = {
let isMounted = true; // 防止组件卸载后更新 state
const fetchData = async () = {
try {
const res = await fetch('/api/lego-config');
const result = await res.json();
if (isMounted) {
setData(result);
setLoading(false);
}
} catch (err) {
if (isMounted) {
setError(err.message);
setLoading(false);
}
}
};
fetchData();
return () = {
isMounted = false; // 清理函数
};
}, []);
if (loading) return divLoading.../div;
if (error) return divError: {error}/div;
if (!data) return null;
return (
ul
{/* 使用可选链操作符，双重保险 */}
{(data.items || []).map(item = (
li key={item.id}{item.name}/li
))}
/ul
);
}
复现与修复代码
要复现这个坑，只需在 API 响应中故意延迟 2 秒，并在 data 为 null 时运行错误代码。你会看到控制台抛出 TypeError: Cannot read properties of null (reading 'items')。使用正确写法后，页面会先显示“Loading...”，数据到达后无缝切换为列表，若接口报错则显示错误信息，用户体验平滑且健壮。
规避建议
始终初始化 State 为合理默认值：如 [] 而非 null，或使用 null 但配合条件渲染。
使用可选链 ?.：data?.items?.map 是现代 JS 的标配，能有效防止深层属性访问崩溃。
处理组件卸载：在 useEffect 返回清理函数，防止内存泄漏和警告。
统一错误处理：封装 API 请求函数，统一捕获错误，避免每个组件重复写 try-catch。
坑三：样式污染与全局变量覆盖
现象：为什么我的乐高组件在别的页面变样了？
【关于乐高】组件库通常强调“可复用”，但样式隔离往往是薄弱环节。你可能会发现，在一个页面里组件样式正常，但放到另一个页面，字体大小、颜色、边距全乱了。或者，你修改了全局 CSS 变量，结果所有乐高组件的默认样式都被覆盖，导致视觉混乱。这种“样式污染”是 CSS 作用域问题在组件化架构下的典型体现。
根本原因：CSS 全局作用域与组件隔离缺失
传统 CSS 是全局的，选择器会匹配页面中所有符合条件的元素。如果乐高组件内部使用了类名 .card，而页面其他部分也有 .card，两者就会互相干扰。虽然 CSS Modules 或 Styled Components 可以解决部分问题，但如果【关于乐高】组件库本身没有做好命名空间隔离，或者开发者在全局样式中覆盖了组件的内部类名，问题依然会发生。此外，CSS 变量的继承机制容易被滥用，导致局部修改影响全局。
正确写法对比
错误写法（全局类名 + 全局变量覆盖）：
/* global.css */
:root {
--primary-color: #007bff;
}
/* 全局覆盖，影响所有使用 .card 的组件 */
.card {
border-radius: 0 !important;
box-shadow: none !important;
}
// LegoCard.js
function LegoCard() {
return (
div className=card
h3标题/h3
p内容/p
/div
);
}
正确写法（CSS Modules + 局部作用域变量）：
/* LegoCard.module.css */
.card {
border-radius: 8px;
box-shadow: 0 2px 4px rgba(0,0,0,0.1);
padding: 16px;
/* 使用局部变量，避免被全局覆盖 */
--card-bg: #fff;
background-color: var(--card-bg);
}
// LegoCard.js
import styles from './LegoCard.module.css';
function LegoCard() {
return (
div className={styles.card}
h3标题/h3
p内容/p
/div
);
}
复现与修复代码
复现方法：在项目中同时引入两个不同库的组件，它们都使用了 .card 类名。观察其中一个组件的样式是否被另一个库的全局样式覆盖。使用 CSS Modules 后，类名会被哈希化（如 LegoCard_card_12345），彻底避免冲突。同时，将 CSS 变量定义在组件内部或局部作用域，确保不被全局 :root 中的变量意外覆盖。
规避建议
强制使用 CSS Modules 或 Scoped CSS：在团队规范中禁止直接使用全局类名。
BEM 命名法：如果无法使用 CSS Modules，严格遵循 Block-Element-Modifier 命名，如 lego-card__title，降低冲突概率。
避免 !important：这是样式调试的最后一招，用多了会让维护变成噩梦。
设计令牌（Design Tokens）：统一管理颜色、间距等变量，通过 JSON 或 JS 对象注入，而非依赖 CSS 变量的继承。
坑四：依赖版本冲突与幽灵依赖
现象：为什么本地能跑，部署就挂？
这是最隐蔽也最致命的坑。你在本地开发时，【关于乐高】组件库版本是 2.1.0，运行正常。但部署到测试环境后，突然报错“Module not found”或“Function is not defined”。检查后发现，生产环境的 node_modules 中，乐高库被提升到了 3.0.0，而该版本删除了你正在使用的某个 API。这种“幽灵依赖”问题，往往源于包管理器的嵌套依赖解析机制。
根本原因：Node 模块解析算法与版本锁定缺失
Node.js 的模块解析算法会向上查找 node_modules。如果多个包依赖同一库的不同版本，NPM 可能会将主版本提升到顶层，而子版本保留在嵌套目录中。如果你的代码直接引用了顶层的库，而实际运行时加载的是嵌套的旧版本（或反之），就会出现版本不一致。此外，package.json 中如果使用了 ^ 或 ~ 范围符，不同时间安装可能得到不同版本，导致环境差异。
正确写法对比
错误写法（未锁定版本，依赖提升）：
// package.json
{
dependencies: {
lego-ui: ^2.0.0,
my-lib: 1.0.0
}
}
假设 my-lib 内部依赖 lego-ui@3.0.0，NPM 可能将 lego-ui@3.0.0 提升到顶层，覆盖你的 ^2.0.0。
正确写法（精确版本 + package-lock.json 提交）：
// package.json
{
dependencies: {
lego-ui: 2.1.0,
my-lib: 1.0.0
}
}
并确保 package-lock.json 或 yarn.lock 被提交到版本控制系统。
复现与修复代码
复现方法：在本地删除 node_modules 和 package-lock.json，重新执行 npm install。对比两次安装后的 lego-ui 版本。使用精确版本并锁定 package-lock.json 后，每次安装都会得到完全相同的依赖树，消除环境差异。
规避建议
提交 Lock 文件：package-lock.json 是项目的“快照”，必须提交到 Git。
使用精确版本：对于核心依赖，尽量避免 ^ 和 ~，指定精确版本号。
定期审计依赖：使用 npm audit 或 yarn audit 检查已知漏洞和版本冲突。
Docker 化部署：将 node_modules 打包进 Docker 镜像，确保生产环境与开发环境完全一致。
总结与行动指南
【关于乐高】项目的稳定性，不取决于你写了多少代码，而取决于你如何管理状态、数据、样式和依赖。这四个坑，每一个都足以让项目在生产环境崩溃。记住，防御性编程和环境一致性是资深开发与初级开发的分水岭。
不要等到上线后才发现问题。现在就去检查你的项目：
是否有直接修改 Props 的代码？
异步数据加载是否有 loading 状态？
CSS 是否使用了模块化隔离？
package-lock.json 是否已提交？
完成这四步，你的项目稳定性至少提升 50%。
还有什么不懂的？评论区留言挨个回。