docs: 优化高性能文档内容 — 提升压测与消息队列知识准确性

- 调整压测指标、测试分类、全链路压测和工具选型内容

- 修正 RabbitMQ、RocketMQ、分库分表、SQL 优化等文档表述

- 润色部分分布式、操作系统和 Spec Coding 文档措辞

- 验证：git diff --check

Author: Snailclimb

docs/ai-coding/practices/spec-coding.md

@@ -340,7 +340,7 @@ bcrypt 自带随机盐，数据库只保存哈希值，不保存明文密码。
 - **目录结构**：树状图说清代码、测试、文档分别放哪。涉及新增文件时才需要。
 - **Git 规范**：分支名、commit message、PR 要求。涉及 Git 操作时带上。
 
-这么分的原因很直接：全局约束几乎每次都要遵守，值得常驻。其他的按任务加，避免上下文里堆太多不相关的内容。Spec 塞越多，AI 反而越容易漏掉真正重要的那几条。
+这么分看的是使用频率：全局约束几乎每次都要遵守，值得常驻。其他的按任务加，避免上下文里堆太多不相关的内容。Spec 塞越多，AI 反而越容易漏掉真正重要的那几条。
 
 ## 三色标签：AI 能干什么、不能干什么
 

docs/cs-basics/operating-system/file-system.md

@@ -186,7 +186,7 @@ Linux 官方 VFS 文档把几个对象讲得很直接：
 
 ![硬链接和软链接对比](https://oss.javaguide.cn/github/javaguide/cs-basics/operating-system/file-hardlink-symlink.webp)
 
-硬链接不能跨文件系统，原因很直接：inode 号只在当前文件系统内有意义。另一个文件系统有自己的 inode 表，同一个数字不代表同一个文件。
+硬链接不能跨文件系统，因为 inode 号只在当前文件系统内有意义。另一个文件系统有自己的 inode 表，同一个数字不代表同一个文件。
 
 可以用下面的命令做个小实验：
 

docs/distributed-system/protocol/byzantine-generals-problem.md

@@ -198,7 +198,7 @@ PBFT 允许网络消息丢失、延迟、重复和乱序，也允许故障节点
 
 这张表只是常见模型总结，不是所有协议都无条件遵循的通用定律。可信硬件、混合故障模型、不同网络假设和不同安全目标，都可能改变副本数要求。
 
-普通 Java 后端系统大多数时候用不到 BFT。原因很直接：服务节点通常属于同一个组织、同一套权限体系、同一套运维系统，节点之间默认可信。你要解决的主要问题是高可用、主从切换、日志一致性、脑裂避免，而不是防止自己的节点主动给其他节点撒谎。
+普通 Java 后端系统大多数时候用不到 BFT，因为服务节点通常属于同一个组织、同一套权限体系、同一套运维系统，节点之间默认可信。你要解决的主要问题是高可用、主从切换、日志一致性、脑裂避免，而不是防止自己的节点主动给其他节点撒谎。
 
 但在这些场景里，拜占庭故障就不能轻易忽略：
 

docs/distributed-system/protocol/centralized-and-decentralized.md

@@ -47,7 +47,7 @@ Leader、Quorum、Lease、Lock、Fencing Token 主要围绕决策和执行资格
 
 单机系统里，很多事情可以直接靠本地内存、数据库事务或进程锁完成。到了分布式系统里，这些办法突然不够用了。
 
-原因很直接：节点之间隔着网络。
+分布式系统多了一层网络，不确定性也跟着来了。
 
 每个节点只能看到自己的本地状态，以及已经收到的消息。某个节点没有响应，可能是真的宕机了，也可能是网络抖动、GC 暂停、磁盘 I/O 卡住、线程池打满。调用方看到的超时，只能说明自己在指定时间内没有收到结果，不能证明对方一定没有执行。