企业官网建设流程全解析

React用起来就感觉和面向对象很违背

// useState<number>(0)：向 React 申请一个“盒子” // 这个“盒子”用来存储 MarchingArmy 的启动时间，初始值为 0 // setArmyTime：这是修改这个盒子的函数。 // 之后，存储从 Army 收到的广播时间 const [armyTime, setArmyTime] = useState<number>(0);//setArmyTime：这是修改这个盒子的函数。

对于小公司, 小的公司操作，其实面向对象更实用一点，而不是任何系统都需要大体量的数据展示，而又需要跨平台页面（）

React很简单的启动

npm create @quick-start/electron three-overlay -- --template react-ts cd three-overlay npm install npm run dev

向我这种小公司小透明，很简单就用React 框架启动一个项目

React 整体一个视图渲染层

Vue其实对程序员更友好一点

你的直觉非常敏锐！很多从 Vue 转过来的人都会有同样的困惑。你说得对，React 和 Vue 在解决程序员问题（响应式数据绑定、组件化）上确实殊途同归，甚至 Vue 对新手更友好。

但如果你去问 React 的创造者（Meta/Facebook），他们会告诉你：“React 根本不是一个框架，它甚至算不上一个完整的库，它的核心是一个『视图渲染引擎』。”

下面我帮你彻底拆解一下你提到的两个问题：React 的核心到底是什么？它和 Vue 的根本区别在哪？

1. React 的核心：极简的“视图状态机”

你觉得 React 是个带渲染组件的库，完全正确。它的核心其实只干一件事：

UI = f(state)（UI 是状态的函数）

React 并不关心你怎么发请求、怎么管状态、怎么路由。它的真正底层（react和react-dom包）只负责：

1. 接收你的state。

2. 算出当前的页面长什么样（Virtual DOM）。

3. 极其高效地把变化的部分更新到真实浏览器 DOM 上。

这就是 React 眼中的“渲染核心”。它就像一个极度严苛的计算器，只要你的输入（State/Props）变了，它就会重新算一遍并更新视图。

2. 为什么需要useEffect？（对比 Vue）

在 Vue 里，我们习惯了“响应式”。数据变了，视图自动变；我在watch或mounted里写点逻辑，非常顺手。

但在 React 的“渲染核心”里，渲染过程（Render）必须是纯函数。React 在算页面的时候，极其讨厌“副作用”——因为在 React 18 的并发模式下，计算过程可能会被暂停、丢弃、甚至执行两次。如果渲染里带了副作用（比如发请求、改全局变量），整个系统就乱了。

那么问题来了：我发请求、绑定时器、打印日志，这些“副作用”往哪写？
如果你的代码只有return <div />，你根本没地方写这些。

于是，React 发明了useEffect。它其实是在告诉你：

“亲爱的程序员，在这个函数里，你随便写定时器、随便发请求。但请你把它们隔离出来。等我把画面渲染（Commit）到屏幕上了，我再来执行你这里的代码。”

所以，useEffect是 React 为了避免自己被“副作用”污染，而强行圈出来的一块“安全区”。

3. Vue 确实更“实用”，但 React 为什么能赢？

你提到“Vue 更实用一点，为了解决程序员问题”。这是业界公认的事实。

• Vue 的哲学是“关怀开发者”：它提供了ref、watch、computed、v-if、v-model，把复杂的东西封装得非常优雅。你不需要懂底层原理，只要按它的语法写，就能快速做出东西。

• React 的哲学是“纯函数和可预测性”：它觉得人写的代码太容易出 bug 了。所以它搞出了单向数据流、不可变状态、纯渲染函数。为了保持这种“纯粹”，它强制你把副作用剥离到useEffect里，把状态提升到最顶层。

为什么大厂/复杂项目偏爱 React？

因为当项目大到几十万行代码、几百个组件共享状态、复杂的跨层级通信时，Vue 的“魔法”（隐藏的响应式追踪）有时会变成难以排查的黑盒。而 React 的“笨拙”（纯函数 + 单向流 + 显式依赖）虽然写起来啰嗦，但它绝对可预测。只要数据流向是对的，页面就一定是对的。

为什么React要命名 useEffect()

这是一个非常深刻的问题。你问到了 React 设计的底层哲学：为什么一定要叫useEffect？它到底想表达什么？

要理解这个名字，我们要把它拆成两部分：Effect（副作用）和use（使用/注入）。这跟跨线程、跨进程其实没有直接关系，它的核心是为了隔离纯计算和外部交互。

以下是这个名字的由来和背后的设计逻辑：

1. 为什么叫Effect（副作用）？

在计算机科学和函数式编程中，“纯函数”是指：只要输入相同，输出必定相同，且不会对外部世界产生任何影响。

但在 UI 开发中，我们不只要“计算画面”，还要做很多“对外部世界产生影响”的事，比如：

• 修改 DOM：手动操作浏览器文档（比如绑定事件监听器、修改滚动位置）。

• 网络请求：发出 Fetch 请求。

• 定时器：启动setInterval或setTimeout。

• 订阅事件：订阅 EventBus（比如你代码里的bus.on）。

这些操作不属于 React 的渲染核心（Render），它们是在渲染完成之后，对“外部系统”产生的影响。在函数式编程术语里，这被称为Side Effect（副作用）。React 官方把这类操作统称为“Effect”。

2. 为什么叫use（Hook 的命名规范）？

React 规定，所有的 Hook（钩子）必须以use开头。这是为了让开发者一眼看出来：“这是一个 React 提供的特殊能力”。
所以，将“使用（use）”和“副作用（Effect）”组合起来，就是useEffect。

3. React 为什么非要设计这个 API？（它解决了什么痛点）

如果你用过早期的 React（Class 组件时代），你会发现副作用通常写在componentDidMount、componentDidUpdate和componentWillUnmount这三个生命周期函数里。

问题在于：
当你有一个复杂的逻辑（比如你的“暂停恢复定时器”），如果拆在三个不同的函数里，代码会非常分散。

• componentDidMount：启动定时器。

• componentDidUpdate：如果paused变了，清理并重启定时器。

• componentWillUnmount：清理定时器。

useEffect的革命性在于：
它把“建立（Setup）”和“清理（Cleanup）”放在了同一个函数里。正如你刚刚写的代码：

tsx

useEffect(() => { // 1. 建立：启动定时器 const timer = setInterval(...); // 2. 清理：返回的函数会在下一次 Effect 执行前、或者组件卸载时触发 return () => clearInterval(timer); }, [paused]);

React 内部帮你管理了生命周期：只要paused变了，或者组件被销毁了，它就会自动去执行你返回的清理函数。名字里的Effect，就是告诉你：“你在这里写的东西，是用来和外部世界打交道（副作用），而不是用来算 UI 的。”

4. 关于你说的“跨线程、跨进程”

React 本身是运行在 JavaScript 的主线程上的（它是单线程的），它并没有跨线程。真正跨线程的是：

1. 浏览器：V8 引擎负责执行 JS，渲染引擎（Blink）负责排版和绘制，GPU 负责合成。useEffect是在 JS 线程执行的，但它修改 DOM 后，浏览器线程会去绘制。

2. Electron：主进程和渲染进程才是跨进程（IPC 通信）。

为什么看起来像是在跨线程？
因为useEffect的执行时机很特殊。React 会先计算好虚拟 DOM，把它提交（Commit）给浏览器渲染到屏幕上，之后才会去执行useEffect里的代码。这种“先画画面，再执行副作用”的机制，让你感觉它像是在幕后异步处理事情。

总结一下：
React 用useEffect这个名字，是在告诉开发者：“这里面放的不是渲染 UI 的代码，而是会改变外部世界状态的副作用代码。”它只是一个用来统一管理副作用生命周期的容器。你觉得它在“跨线程”，是因为它确实是在画面渲染之后（异步）才执行的，但这只是它在底层调度策略的一种表现，而非命名原因。

参考 -无厘头 -没什么用的虚幻盒子

是可以加载各个虚幻项目，但只是目录定位而已

再深入一点的搜索，置换，报表等工具就没有

一半完整的截图如下

（不是卖品牌或者广告，内容只有截图一半，反而是截取到了一些其他品牌，不好意思）

真个品牌工具图就是如此，但重点是：如果有看我之前的文章应该都知道，我喜欢写一些备注，改一些颜色，这个工具现在v3.0版本就是能够把一些“细节”都完全复制，粘贴了；引用和跳转估计是没有，但是单个蓝图，是能实现完全可视化，包括各种字体，位置等等，是完全“精细”的可视化