浏览器拿到 HTML 后的渲染分五步：解析 HTML 构建 DOM 树；解析 CSS 构建 CSSOM 树；两者合并成渲染树（只含可见节点）；布局（layout）计算每个节点的几何信息；绘制（paint）生成位图，最后合成（composite）由 GPU 把图层拼成最终画面。性能优化就藏在关键路径里：JS 默认阻塞 HTML 解析，把非关键脚本加 async/defer；CSS 阻塞首次渲染，首屏关键 CSS 内联、非关键样式延迟加载；避免"强制同步布局"——别在循环里交替读写 offsetWidth 这类布局属性，读写分离、批量操作；动画优先用 transform 和 opacity，它们只走合成层，不触发重排重绘。实用建议：用 Lighthouse 或 Performance 面板定位阻塞资源；长列表用虚拟滚动，把 DOM 节点数控制在几百以内。

Raft PreVote 机制详解一、先回顾原生 Raft 的问题：分区恢复后掉线节点频繁触发选举原生 Raft 选举规则每个节点有任期 (term)，term 单调递增；节点发现自己的 term 收到 RPC 里的 term → 立刻更新自己 term，转为 follower；节点超时没收到 leader 心跳，term+1，发起 RequestVote（正式投票请求）竞选 leader。网络分区场景（问题来源）假设集群 3 节点 A (leader)、B、C，发生网络分区：A 单独一个分区，继续作为 leader，不断发送心跳，term 保持增长；B、C 掉线 / 在另一个分区，收不到 leader 心跳，B 超时 → term+1，发起 RequestVote。 分区恢复，网络连通： B（高 term）的RequestVote发给 A（旧 term）。 A 收到请求，发现对方 term > 自己 term → A 直接更新自身 term，立刻降级为 follower。关键痛点：哪怕 B 根本拿不到多数选票，仅仅是发起正式投票 RequestVote，就会强制提升集群里其他节点的 term，废掉当前 leader。 分区恢复后，掉队节点持续超时、不断term+1发投票请求，每次发包都会冲击现有 leader，反复触发不必要的选举，集群反复震荡。 而且 term 持续膨胀，日志复制也会受干扰。一句话总结原生 Raft 缺陷：发起正式投票 RequestVote 的动作本身就会增加 term，破坏现有 leader，哪怕候选人不可能赢得选举。二、PreVote（预投票）解决思路：预投票阶段不增加任期 termPreVote 把选举拆成两个阶段：PreVote（预投票）→ RequestVote（正式投票）核心原则：只有预投票拿到多数同意之后，候选人才会真正递增 term，发起正式选举。预投票全程不修改任何节点的 term。完整流程节点收不到 leader 心跳，准备竞选；先不 term+1，发送 PreVote RPCPreVote 请求携带：候选人当前 term（term 还没加 1）含义：“大家是否同意我尝试开启新一轮选举？”Follower 收到PreVote如何判断：规则：follower 只有认为当前集群没有有效 leader，才同意预投票 判断条件：候选人的日志至少和自己一样新（和原生 Raft 投票日志校验规则一致）；本地最近收到 leader 心跳已经超时（当前没有可用 leader） ✅ 满足 → 返回同意 PreVote；❌ 不满足 → 拒绝。⚠️ follower 响应 PreVote 时，不会更新自己 term！候选人收集预投票结果：如果拿到多数节点预投票同意：这时才执行 term += 1，然后发送正式RequestVote，进入正常竞选；如果预投票失败（没拿到多数）：不增加 term，放弃本次竞选，等待下次超时。回到刚才分区恢复场景看 PreVote 效果分区恢复后，掉队节点 B 想要发起选举：B 发送 PreVote，term 还是旧值，没有自增 term；集群里 A 是有效 leader，A 收到 PreVote，心跳还没超时 → 直接拒绝 PreVote；B 预投票失败，不会递增 term，不会发送正式 RequestVote；leader A 的 term 不会被冲击，继续提供服务，不会无故降级。✅ 解决了原生 Raft 的核心问题：掉队节点无法仅凭发投票请求就拉高集群 term、干掉当前 leader。三、PreVote 的几个关键细节PreVote 不修改任何节点的 term term 递增被推迟到预投票成功之后。这是 PreVote 最核心的设计，也是题目问的：在不增加任期的前提下提前校验是否有机会当选。日志校验逻辑保留 PreVote 依然会校验日志新旧，和原生 RequestVote 规则相同：follower 不会把预投票投给日志落后的节点，防止日志落后节点强行发起选举。依然保留选举超时 预投票失败后，候选人依旧会随机等待选举超时，再尝试下一轮 PreVote，避免重复风暴。PreVote 不是 Raft 论文原版，是工程优化（etcd、Consul 都实现） 原版 Raft 没有 PreVote，这个机制是为了解决网络分区下的幽灵选举（spurious election）引入。四、PreVote 的局限（补充）PreVote不能完全杜绝选举，只是杜绝无效选举； 如果真的 leader 宕机，预投票会成功，然后正常走正式选举流程。多轮 PreVote 会多一轮 RPC 开销，换集群稳定性；PreVote 不能解决脑裂，依然依赖多数派机制。