State与Props：React Native里最不该被轻视的“电路接口”
你有没有遇到过这样的场景？
用户在商品页点了三次“加入购物车”，界面上只显示+1；
表单输入框刚打完字，焦点突然丢失、内容清空；
Tab切换回来，图片轮播器从第一张重新开始——而用户明明记得自己停在第三张。
这些不是UI库的bug，也不是原生桥接层的问题，更不是JavaScript引擎的锅。它们几乎都指向同一个根源：State和Props的边界被悄悄越过了。
就像一个硬件工程师不会把电源正极直接焊到地线上，React Native开发者也必须理解——props是受控输入信号，state是本地储能节点。二者之间那条看不见的“隔离带”，一旦短路，整个组件树的时序、一致性与可预测性就会崩塌。
为什么说Props像理想电压源，State像带电容的局部节点？
我们不妨用电子系统类比来建立直觉：
Props是父组件提供的只读输入信号，类似一个内阻为零的理想电压源：它稳定、可预期、不可反向驱动。你不能往里面灌电流（修改它），也不能指望它随你的负载变化而自动调整（它不响应子组件内部变化）。它的唯一职责，是把上游决策结果，干净、准时、无歧义地送达。
State则像一个带储能电容的局部节点：它有自己的“惯性”（初始值）、充放电时序（异步更新队列）、以及对扰动的响应能力（如用户输入、网络响应）。你必须主动给它“充电”（
setState），它才会改变电位（触发重渲染）；若试图用镊子直接掰弯引脚（obj.name = 'new'），电容根本没感知，输出电压纹丝不动。
这个类比不是修辞，而是设计契约的真实映射。React Native的Diff算法、Fiber调度器、甚至原生视图挂载逻辑，全部建立在这个前提之上。
State：别把它当变量，要当“事务指令”
很多开发者写const [count, setCount] = useState(0)，心里想的是：“哦，定义一个叫 count 的变量”。这恰恰是陷阱的起点。
count不是变量，它是某一帧渲染快照中，该组件对数据的只读投影。真正能改变它的，只有setCount这个函数——它不是赋值操作，而是一条提交到React事务队列的不可撤销指令。
关键机制你必须知道：
✅批处理不是优化，而是语义必需
你在onPress里连调三次setCount(c => c + 1)，React不会执行三次渲染。它会合并成一次：count: 0 → 3。这不是性能技巧，而是保证“状态变更原子性”的底层契约。如果你依赖中间态（比如想在+1后立刻读取新值），说明架构已偏离React范式。✅闭包捕获的是“快照”，不是“实时值”
javascript useEffect(() => { const timer = setTimeout(() => { console.log(count); // 永远是首次渲染时的值！ }, 1000); return () => clearTimeout(timer); }, []); // 空依赖数组 → 闭包锁定初始count
这不是Bug，是设计。若需访问最新值，用useRef存一份可变引用，或改用函数式更新回调中的p
