React生命周期这个话题说老不老说新也不新。我最早接触React的时候还在老老实实写类组件componentWillMount、componentWillReceiveProps这些方法用得飞起后来React 16.3一出来直接给我打懵了——一批生命周期被标记为UNSAFE_再后来React 17、18一路升级函数组件和Hooks成了主流面试的时候被问生命周期问的已经不是“背出几个方法名”而是“为什么要废弃will系列”“Fiber对生命周期到底做了什么”。这篇文章我想把生命周期这件事从头到尾捋一遍。不管你是刚学React、准备面经还是已经在业务里写了几年React但没时间系统看源码这篇内容都能帮你把类组件生命周期、Hooks替代方案、React 18并发模式下的变化、以及面试里最高频的那几个对比问题一次性讲透。我尽量用大白话加实际代码来讲不会整一堆看不懂的源码术语堆砌。1. 为什么前端都要谈生命周期1.1 生命周期到底在解决什么问题说白了一个组件从被创建到显示在页面上再到数据更新重新渲染最后到从页面上消失这整个过程就像一个人的一生出生、成长、工作、退休、离世。React给这个过程的每个关键节点都开了一个“钩子”允许你在特定的时间点执行自己的代码这些钩子就是生命周期。你可能会问我不写生命周期行不行当然行写个纯展示组件函数一写、return一段JSX就完事了什么都不用管。但只要你的组件需要做下面任何一件事就绕不开生命周期组件挂载后需要拉取接口数据组件收到新的props时需要做一些处理组件卸载时需要清理定时器、取消订阅、移除事件监听组件渲染前后需要操作DOM、测量尺寸这些需求如果不在正确的时机执行就会出现数据没拿到、页面闪一下、内存泄漏、重复请求这些问题。我在实际开发中见过最典型的一个BUG就是同事在componentDidMount里开了个setInterval去轮询接口结果没在componentWillUnmount里清除页面切走再切回来定时器叠加了好几个接口请求直接把后端打挂了。这就是不明白生命周期时机导致的血泪教训。1.2 从类组件到函数组件的演进逻辑React生命周期这套东西最早是跟着类组件一起出现的。class组件里this指向实例本身可以在不同阶段的方法里维护状态和处理逻辑结构上很清晰。但类组件有几个让人头疼的问题this指向容易搞晕、逻辑分散在多个生命周期方法里难以复用、代码量偏大。后来React团队推出Hooks函数组件也能有状态和副作用了。useEffect、useLayoutEffect这些Hooks本质上就是在“模拟”原来类组件的生命周期但是粒度更细、组合更灵活。很多新手一上来就学函数组件看到useEffect里传不传第二个参数迷宫一样的差异直接懵了。其实只要理解了类组件生命周期那套时间线再看Hooks就会豁然开朗——它们只是换了一种写法底层的时间线还是那条时间线。甚至可以说React 16.3之后官方一直在引导大家从“生命周期方法”的思维转向“副作用时机”的思维。你不再需要在componentDidMount和componentDidUpdate里各写一遍一样的逻辑一个useEffect配上正确的依赖数组就能搞定。2. 类组件生命周期全拆解2.1 挂载阶段从constructor到componentDidMount类组件的生命周期分成三大阶段挂载、更新、卸载。挂载阶段按顺序执行的方法如下constructor(props) { super(props); this.state { count: 0 }; } static getDerivedStateFromProps(props, state) { // 根据props计算state返回值会合并到state中 return null; } render() { return div{this.state.count}/div; } componentDidMount() { // 组件已经挂载到真实DOM上 }顺序是constructor → static getDerivedStateFromProps → render → componentDidMount。这里有几个容易踩坑的点constructor里不要调用this.setState因为在初始化阶段直接给this.state赋值就够了。constructor里也不要写副作用代码比如发请求这时候组件还没挂载请求回来你也操作不了DOM。constructor是唯一一个可以初始化this.state的地方但它不是必须写的如果你不需要初始化state完全可以省略。我见过很多人在constructor里写this.handleClick this.handleClick.bind(this)这种绑定操作的这在class属性语法出现之前是标准写法现在有了箭头函数class属性基本可以告别手动bind了。这个不是生命周期方法本身的问题但面试里经常放在一起问。static getDerivedStateFromProps这个方法是16.3新增的目的是取代componentWillReceiveProps。它是一个静态方法里面没有this不能调用任何实例方法只能根据props和state计算新state然后返回。这个设计很刻意就是为了强制你写纯函数式的逻辑避免在里面搞副作用。实际业务里绝大多数情况不需要用这个方法因为React官方文档都明确说过大部分场景用这个方法是多余的还会引入bug。如果你只是想根据props变化重新请求数据在componentDidUpdate里做比用它安全得多。componentDidMount是挂载阶段最常用的方法只在组件挂载完成后调用一次。此时DOM已经真实存在可以放心做这些事请求接口、操作DOM、添加事件监听、连接WebSocket、初始化第三方库。注意这个方法和后面的componentDidUpdate、componentWillUnmount合称“三大主力”面试里让你写一个组件从挂载到卸载的完整流程基本就是围绕这三个方法展开的。2.2 更新阶段render前的那些事当组件的props变化、state变化或者父组件重新render导致子组件需要重新渲染时组件就进入了更新阶段。更新阶段的执行顺序如下static getDerivedStateFromProps(props, state) { return null; } shouldComponentUpdate(nextProps, nextState) { // 返回false可以跳过本次渲染 return true; } render() { ... } componentDidUpdate(prevProps, prevState, snapshot) { ... }顺序是static getDerivedStateFromProps → shouldComponentUpdate → render → componentDidUpdate。16.3之前还有一个componentWillReceiveProps用来在props变化时做一些处理但现在已经废弃了统一用getDerivedStateFromProps和componentDidUpdate来替代。这里必须强调一点componentWillReceiveProps有一个非常大的坑就是父组件不管传进去的props有没有实际变化只要父组件重新render了它就会被调用导致很多人不明不白地在这里发请求、setState引发死循环。shouldComponentUpdate是性能优化的关键方法。返回false可以阻止这次渲染但注意即使返回false子组件的componentWillReceiveProps如果是老版本或者getDerivedStateFromProps还是会被调用只是不会继续执行render。在React 16之前这个方法是手动优化性能的主要手段现在的话更建议直接用React.PureComponent它会自动做一次浅比较省得你手动写比较逻辑。componentDidUpdate接收prevProps、prevState两个参数还有一个snapshot参数这个snapshot是getSnapshotBeforeUpdate方法的返回值。getSnapshotBeforeUpdate在render之后、DOM更新之前调用适合用来读取一些更新前的DOM信息比如滚动位置。这个方法在16.3新增主要是为了替代componentWillUpdate。老实说这个API平时用得不多但在做聊天窗口、无限滚动列表这类需要处理滚动位置的场景非常好使。组件每次更新都会执行一遍这整条链。新手最容易犯的错误是在componentDidUpdate里直接setState因为setState会导致组件再更新然后componentDidUpdate又触发又setState……直接栈溢出。如果确实需要在componentDidUpdate里setState一定要加条件判断比如比较prevProps和this.props的值不一样才setState。2.3 卸载阶段与错误边界卸载阶段只有一个方法componentWillUnmount() { clearInterval(this.timer); window.removeEventListener(resize, this.handleResize); }这个方法在组件从DOM上移除之前调用用来做清理工作清除定时器、取消网络请求、移除事件监听、断开WebSocket连接、销毁第三方库实例。如果不做这些清理轻则内存泄漏重则组件卸载后setState触发警告甚至会修改到不该修改的数据——React 18之前调用一个已卸载组件的setState会打印警告18之后警告取消了但依然是不良实践。另外还有一个特殊的存在错误边界Error Boundary。React 16引入了componentDidCatch和static getDerivedStateFromError用来捕获子组件在渲染过程中抛出的错误避免整个应用白屏。这两个方法算是生命周期体系里的“应急通道”也是React 16之后前端界非常关注的一个能力。面试里如果能主动提一嘴错误边界通常会给面试官留下好印象。3. Fiber和并发模式React生命周期背后的大手术3.1 Stack协调器为什么扛不住聊生命周期很多人只背方法名却不理解React为什么要改生命周期。这背后的真正原因是Fiber架构。React 16之前协调器是Stack Reconciler从名字就能看出来它依赖调用栈来递归处理组件树。递归的过程一旦开始就不能中断如果一个组件树很复杂更新任务又很重主线程就会被一直占用用户输入、页面动画都卡住表现就是掉帧、白屏。Fiber的核心理念是“可中断的渲染”。React把更新任务拆分成一个个小单元每个单元做完之后让出主线程浏览器有时间去处理用户事件、绘制帧然后再接着做。同时Fiber还引入了优先级概念紧急的更新比如用户输入可以插队不紧急的更新比如数据预取可以让路。这个架构转变直接对生命周期方法产生了影响——既然render阶段可以被中断、被恢复甚至被丢弃重来那原本在render阶段里做的事情就变得危险了。比如componentWillMount这个方法名听着像“挂载前”很多人喜欢在里面发请求、订阅事件但问题是因为渲染可以被中断componentWillMount可能被调用多次也可能在真正的挂载之前被中断你发的请求、建的订阅就可能重复、浪费甚至产生错误。3.2 render phase被调用多次带来的变化React 16之后整个更新过程被明确分成两个阶段render phase和commit phase。render phase负责计算“新的UI应该长什么样”也就是调用函数组件本身、类组件的render方法、以及getDerivedStateFromProps、shouldComponentUpdate这些方法。这个阶段可以被打断也意味着所有处于这个阶段的生命周期方法都可能被调用多次。React官方给出的建议是render phase里的方法必须是无副作用的也就是不能修改外部状态、不能发请求、不能写DOM。commit phase则负责把计算好的结果提交到真实DOMcomponentDidMount、componentDidUpdate、componentWillUnmount、useLayoutEffect都发生在这个阶段。commit phase是同步的、不可中断的这也是为什么挂载、更新、卸载这些操作副作用的方法是安全的。这就是为什么React要废弃componentWillMount、componentWillReceiveProps、componentWillUpdate这三个方法——它们都处于render phase名字却暗示着“将要发生什么”太容易诱导开发者写副作用代码了。官方不是把它们删了而是加了UNSAFE_前缀意思是如果你坚持用你得知道自己在冒险。到React 17之后除了保留UNSAFE_前缀的兼容版本表面上的will方法就彻底看不到了。3.3 React 18严格模式下的“双重调用”React 18发布之后严格模式StrictMode下多了一个很有意思的机制组件挂载时会先执行一遍render phase卸载掉再重新挂载一次。也就是说在开发环境下你的组件函数可能会被调用两次useEffect的mount和unmount也会执行两遍。很多人第一次遇到这个现象都以为是Bug其实这是React刻意为之目的是帮你暴露出“不可重入”的副作用代码。举个例子如果你在useEffect里创建了一个WebSocket连接正常挂载时只执行一次但在React 18严格模式下它会执行创建连接 → 清理连接 → 再创建连接。如果你的清理逻辑写得不干净或者根本没写清理逻辑控制台会立刻暴露问题。React团队称之为“reusable state”意思是组件应该具备“卸载后重新挂载而不出错”的能力。这个特性对大家的启示是所有副作用代码必须写成可清理的。你在useEffect里做了什么就必须在return的清理函数里撤销什么。这不仅是为了通过严格模式检测更是为了组件在真实场景下不会因为复用、缓存、切换而翻车。4. Hooks体系如何接管生命周期4.1 useEffect模拟DidMount和WillUnmount函数组件里没有componentDidMount、componentDidUpdate这些方法替代它们的主力是useEffect。useEffect的写法useEffect(() { // 这里相当于 componentDidMount componentDidUpdate console.log(副作用执行); return () { // 这里相当于 componentWillUnmount也相当于 componentDidUpdate 的清理阶段 }; }, [deps]);useEffect的执行时机和类组件生命周期不是一个完全对等的关系。它是在浏览器绘制完成之后触发的也就是说不会阻塞页面渲染。如果你的副作用是要改DOM样式、测量元素尺寸用useEffect会出现肉眼可见的闪烁——渲染完成再改样式页面会闪一下。这种场景应该用useLayoutEffect。第二个参数数组控制“何时执行”不传数组每次渲染都执行传空数组[]只有挂载时执行一次严格模式下会有双重调用传依赖值只有依赖变化时才执行。这个依赖数组是大家最容易写错的地方。我见过太多人因为依赖漏掉某个变量导致闭包里用的还是旧值查了半天查不出来。实务建议依赖数组里写上所有你在副作用里用的外部变量然后配合ESLint的react-hooks/exhaustive-deps规则让编译器帮你检查是否漏写。当你想模拟componentWillUnmount时只需要在useEffect里返回一个清理函数useEffect(() { const timer setInterval(() { // 处理逻辑 }, 1000); return () clearInterval(timer); }, []);这里返回的清理函数不只在组件卸载时执行在每次重新执行副作用之前也会先清理上一次的副作用。比如依赖变化导致副作用重新执行时会先把上一次的定时器清掉再创建新的这个特性比类组件里需要手动在componentDidUpdate里比对旧值、再清理再创建要优雅太多。4.2 useLayoutEffect和useInsertionEffectuseLayoutEffect和useEffect唯一的区别是执行时机不同useLayoutEffect是在DOM变更之后、浏览器绘制之前同步执行。也就是说在useLayoutEffect里对DOM做修改浏览器不会出现先画一版样式再改成另一版的闪烁问题。这个Hooks非常适合用来测量DOM元素尺寸、读取滚动位置、同步调整样式。需要注意因为useLayoutEffect是同步执行的如果里面做了耗时操作会阻塞浏览器绘制。所以不要在它里面做重计算、发请求这些事。如果代码在服务端渲染时用了useLayoutEffect会直接警告这时候可以用useEffect代替或者用typeof window undefined判断。useInsertionEffect是React 18新增的Hooks专门给CSS-in-JS库使用的。它在useLayoutEffect之前执行主要用来注入样式。普通业务代码基本不需要用了解即可。这三兄弟的优先级顺序是useInsertionEffect → useLayoutEffect → useEffect一个比一个晚。4.3 常见竞态问题与处理函数组件生命周期里最经典的一个坑是异步请求的竞态问题。页面里发了个请求用户操作导致组件卸载或者参数变化请求才返回来这时候setState就作用在了一个已经不存在的组件上或者更糟糕后发的请求先返回先发的请求后返回数据被旧结果覆盖。这种问题的解法其实很简单使用一个标志位在清理函数里把它置为false。useEffect(() { let cancelled false; fetch(/api/data, { params: { id } }) .then(res res.json()) .then(data { if (!cancelled) { setData(data); } }); return () { cancelled true; }; }, [id]);这段代码的思路是每次副作用执行前清理上一次副作用时把cancelled置为true这样上一次请求回来时就不会去setState了。这个模式在实际业务里非常常用尤其是搜索框的联想词、列表页筛选条件快速切换、详情页跳转这些场景。如果你在用较新的React版本可以试试用useEffect的AbortController配合fetch的signal取消真实请求比单纯用标志位更彻底还能省流量。5. 生命周期在真实场景中的落地5.1 数据请求应该放在哪里面试里常问数据请求应该放在componentDidMount还是componentWillMount正确答案是永远放在componentDidMount或者useEffect的空依赖数组里。原因是componentWillMount在Fiber架构下可能被调用多次而且此时组件还没挂载请求回来你也做不了DOM操作。componentDidMount只执行一次此时组件已经在页面上了可以放心setState、操作DOM。这背后其实就是“render phase不能有副作用”这一个原则。如果在服务端渲染场景下数据请求就更讲究了。SSR需要在服务端把页面渲染成HTML之前就拿到数据。React官方体系里Next.js的getServerSideProps、getStaticProps就是处理这个的如果你自己搭SSR框架可以用renderToString之前做一次数据预取。这部分的热搜词里有“react ssr 数据预获取方案”其实就是这个事在组件渲染之前把所有需要的数据都collect出来一次性注入然后服务端渲染完成。很多人困惑为什么React不像Vue那样有专门的生命周期做SSR数据预取答案是React刻意保持了组件渲染的纯粹性数据预取从架构上被放在框架层解决而不是组件内部。5.2 性能优化减少不必要的重新渲染生命周期与性能优化直接相关的核心是shouldComponentUpdate。老React时代大家疯狂手写这个方法来避免无用渲染后来有了React.PureComponent和React.memo浅比较成为默认操作。到了React 18又有了useMemo和useCallback来缓存引用防止子组件因父组件重新创建函数引用而被迫渲染。但这里有几个必须注意的点React.memo只做浅比较如果props里有对象、数组、函数比较结果往往不可靠需要配合useMemo、useCallback缓存引用。state和props更新时组件一定重新渲染memo挡不住也不该挡但能挡住父组件渲染导致的子组件无意义渲染。生命周期里做性能优化核心思路只有一个让“不相关的数据变化”不触发“不相关的组件渲染”。列Tree哪个节点变了就只更新那个节点别整棵树一起动。实际开发里我推荐优先用React Profilervia React DevTools来看到底是哪个组件浪费了渲染而不是凭感觉加memo、加useMemo。过度优化会让代码可读性急剧下降性能没提升多少维护起来却要命。5.3 React Native白屏与生命周期热搜词里有一条“react navite 在安卓低端机很卡”还有一条“react native 启动白屏”这俩本质上都和生命周期时机相关。React Native和Web React的生命周期方法名称一致但背景完全不同RN的主线程和JS线程是分离的。启动阶段JS Bundle要先加载、执行然后组件才能渲染这个过程在低端安卓机上要好几秒屏幕一直白着。从生命周期角度来看RN的componentDidMount触发时机比Web端晚很多因为它要等JS引擎初始化完成。优化方向通常是把启动阶段的大JS Bundle做拆分和预加载、在原生端先渲染一个静态启动屏、用InteractionManager.runAfterInteractions把非关键任务延后到动画交互结束之后执行。另外如果你的RN页面在componentDidMount里一上来就要渲染大量列表、图片低端机卡顿是必然的可以用虚拟列表FlatList的initialNumToRender和windowSize调整首屏渲染量。这算是一个生命周期使用不当导致性能问题的典型例子。5.4 一个很少人知道的React错误排查技巧热搜词里有一条“dsh-better-sidebar: minified react error #130”这种minified error其实React在压缩后会给你一个错误编号打开对应文档能找到详细说明。React 16之后有个机制生产环境报错会带上错误码大部分情况能通过https://reactjs.org/errors/130这样的链接看到详细解释。我处理这类问题的心得是先用开发环境复现开发环境下的报错信息是完整的。生产环境的minified error多半和Hooks使用顺序、条件渲染导致的Hook不一致有关。排查生命周期相关的报错先看是不是遍历列表时key不对导致组件复用异常再看是不是在错误的生命周期时机操作了DOM或state。6. 高频面试题与对比分析6.1 React生命周期面试题速查我把面试里最高频的生命周期问题整理成一个速查表结合自己的经验不算标准答案模板但思路基本够用高频问题回答要点React生命周期分几个阶段挂载、更新、卸载Fiber架构下可说render phase和commit phase两个阶段componentWillMount为什么废弃render phase可能被多次调用副作用不安全shouldComponentUpdate作用手动控制是否继续渲染返回false跳过渲染getDerivedStateFromProps和componentWillReceiveProps区别前者是静态方法无this、强制纯函数式后者容易滥用且update阶段每次父组件渲染都会被调用componentDidMount里能不能setState可以会触发一次额外渲染但通常没必要能在constructor初始化就不要在挂载后setStatecomponentWillUnmount里要做什么清理定时器、取消订阅、移除监听、销毁第三方实例父组件render子组件生命周期如何变化子组件props变化会触发子组件更新流程getDerivedStateFromProps→shouldComponentUpdate→render→componentDidUpdatesetState在生命周期不同阶段的区别constructor里不能setState、componentDidMount里setState触发额外渲染、shouldComponentUpdate里setState容易死循环面试时我建议多讲“为什么”少背“是什么”。比如谈到componentDidMount时不要只说“组件挂载后调用”而要讲清楚因为此时真实DOM已生成可以操作DOM因为render phase不可靠所以副作用不能放到render之前如果服务端渲染componentDidMount不会在服务端执行所以数据预取必须交给框架处理。这个思路比背答案更能体现你对React的理解深度。6.2 React和Vue生命周期有什么异同Vue的生命周期和React生命周期经常被放在一起比较因为它俩的时间线有很多相似之处。Vue的生命周期包括beforeCreate、created、beforeMount、mounted、beforeUpdate、updated、beforeDestroy现在叫beforeUnmount、destroyedunmounted。从节点上看created对应着React里“组件实例已创建但未挂载”mounted对应componentDidMountupdated对应componentDidUpdateunmounted对应componentWillUnmount。但两者的底层逻辑差异很大。Vue的响应式系统是精细的依赖追踪数据变了只更新相关的渲染Watcher更偏自动React的Fiber架构更强调调度和可中断性也更依赖开发者对副作用时机的把控。Vue 3里有了composition API也支持类似Hooks的写法但它内部的调度模型和React并不同。面试时如果被问“vue和react的区别”不能只停留在模板语法和状态管理上可以把生命周期的调度模型差异拿出来讲这很容易区分出你有没有真正理解框架本身。Vue页面的生命周期和React还有一个现实差异Vue是“组件实例”驱动的beforeCreate时连data都还没初始化React没有这个阶段class组件里constructor一执行this已经指向实例state可以直接初始化。React也没有“模板编译”的概念JSX在编译期就被转成React.createElement调用运行时整个就是个JavaScript对象树。这就是为什么React生命周期如此强调副作用时机因为它没有任何“模板”层面的自动拦截机制。6.3 Fiber的作用一句话说清热搜词里有个“fiber的作用”面试里也是特别爱问的。一句话版本Fiber是把React的渲染更新从不可中断的同步递归改造成了可中断、可恢复、可优先级的任务调度过程。这个改造的直接后果就是“render phase可能会被多次调用、被丢弃”从而引发了生命周期方法的废弃和Hooks体系的兴起。也就是说理解Fiber才能真正理解现代React生命周期设计背后的一切取舍。再往下说一层Fiber把一个组件树变成了一棵链表结构每个Fiber节点保存了组件的类型、props、state、DOM节点引用、以及和其他节点的关联关系。React通过遍历这棵链表可以在时间切片内逐个处理节点处理到哪里停下来记录一下下一片继续从暂停点开始。这就像你读一本很厚的书读着读着去回微信、去吃饭回来从书签位置续读而不是把整本书一口气读完才去做别的事。有了这个机制React才能在浏览器掉帧之前主动“让位”。React 18的并发特性startTransition、useDeferredValue、useTransition都是建立在Fiber可中断渲染之上的。startTransition可以标记一个更新为低优先级如果高优先级更新不断到来低优先级更新会被延后甚至丢弃。这直接改变了我们写生命周期/副作用代码的习惯不再需要担心低优先级的副作用和用户操作抢时间。6.4 React生命中那些容易忽略的冷知识最后补充几个我实际踩过的、面试基本也会考的冷门点第一React.PureComponent和React.memo做的是浅比较。如果你修改的是对象内部属性然后把这个对象的引用原封不动传给子组件父组件渲染时代浅比较认为引用没变子组件会跳过渲染但此时子组件展示的数据其实已经是旧的了。解法是每次修改对象时生成新引用展开运算符或不可变库。第二useEffect的执行时机是浏览器绘制完成后而componentDidMount是commit phase同步执行的。所以如果你在类组件里用componentDidMount读取DOM尺寸再用函数组件useEffect读取两者拿到的结果可能不一致——后者可能晚一帧。这个差异在做动画、布局计算时很关键。第三React 18之前componentWillUpdate里可以读取到更新前的DOM状态现在这类需求交给getSnapshotBeforeUpdate。这个方法的返回值会成为componentDidUpdate的第三个参数。我之前在做聊天页面时就是用它来记录旧列表高度然后等DOM更新后在componentDidUpdate里把滚动位置补回来实现“新消息进来但列表不跳动”的效果实用度很高。第四React严格模式只会在开发环境开启双重调用生产环境不受影响。很多新手以为是代码写错了其实是React在帮你测代码的抗压能力别去关掉严格模式。写在最后聊了这么多最后说几句个人体会吧。生命周期这玩意不同阶段的人理解深度完全不同。刚入门前端的时候我以为是背API、記方法名写了两年业务之后发现生命周期就是“代码在哪个时机跑才不犯错”的纪律问题——该清理的清理、该防竞态的防竞态、不该有副作用的阶段别乱下手再往后啃Fiber源码才明白这些纪律背后都是架构取舍React把“副作用必须是安全的”这个理念硬生生写进了框架的底层设计里。如果你正处于准备面试的阶段我的建议是别把时间花在背生命周期方法名上多想一想“React 16为什么要改这套东西”“Fiber和Hooks为什么是配套出现的”这些才是能让你在面试里脱颖而出的深度思考。如果你只是日常写业务记住一句话也够用副作用放在合适的地方清理逻辑别偷懒竞态条件处处留心——大部分生命周期相关的线上事故都能避免。