build, fix, feat, refactor: 优化长列表性能，新增注册表并发校验，升级v5.1.0

- 前端引入@tanstack/react-virtual虚拟列表库，重构PathTable与MergePreview组件，优化大量路径条目下的渲染性能
- 为后端注册表保存接口添加原始路径比对逻辑，防止并发修改导致的配置覆盖，同步更新前端保存逻辑传递原始路径参数
- 替换core模块手动编写的Windows API FFI声明为windows-sys官方库，简化代码维护
- 完善单元测试，新增空数组处理、边界场景的测试用例
- 更新项目依赖与锁定文件，将版本升级至v5.1.0
- 新增项目代码架构审查文档

docs/code-and-architecture-review.md

@@ -0,0 +1,69 @@
+# PathEditor v5.0 代码与架构审查报告
+
+## 1. 项目概览
+
+PathEditor v5.0 是一个功能完善的 Windows 系统环境变量 (PATH) 编辑器，支持 GUI 与 CLI 双模式。
+技术栈选型现代化且合理：
+- **后端 / 核心逻辑**：Rust (Cargo Workspace)
+- **GUI 框架**：Tauri 2.x
+- **前端**：React 19 + TypeScript + Zustand
+
+整体项目结构清晰，职责划分明确，严格遵循了前后端分离与核心逻辑无平台依赖的设计原则。
+
+## 2. 架构设计审查
+
+### 2.1 Cargo Workspace 三层架构
+项目采用了经典的 Cargo Workspace 模式，分为三层：
+- `core`: 纯 Rust 库 crate，包含所有的核心业务逻辑（注册表读写、备份、配置文件管理、路径验证与清理等）。该层**完全不依赖** Tauri 或 CLI 库，极大地提高了代码的复用性和可测试性。
+- `gui`: Tauri 桌面应用。仅作为薄包装层（Thin Wrapper），通过 `#[tauri::command]` 将 `core` 的功能暴露为 IPC 接口供前端调用。
+- `cli`: 命令行工具层。依赖 `core` 和 `clap` 库，直接提供命令行交互能力。
+
+**审查结论**：架构设计非常优秀。核心逻辑解耦彻底，无论是 GUI 还是 CLI 都能复用同一套安全、经过测试的核心代码。
+
+### 2.2 IPC 通信与状态同步
+前端与 Rust 后端通过 Tauri IPC 进行通信。
+- 所有的错误处理均通过 `Result<T, String>` 返回，前端通过 `Promise` 捕获并处理，用户体验良好。
+- 针对非事务性的双写操作（如同时保存系统和用户 PATH），前端 `app-store.ts` 中使用了 `Promise.allSettled`。当发生部分成功（Partial Success）时，能正确捕获并重新加载注册表状态，避免了前端内存状态与后端注册表状态的漂移（State Drift）。
+
+## 3. 后端代码审查 (Rust)
+
+### 3.1 核心逻辑 (`core`)
+- **安全性与健壮性**：
+  - 在 `registry.rs` 中，严格检查了路径字符串的 Null 字节，以及 32767 个字符的 Windows 注册表长度上限，防止缓冲区溢出或写入失败。
+  - 使用了安全的 `winreg` 库进行注册表操作。
+- **FFI 调用**：
+  - 在 `system.rs` 中调用 Windows API（如 `ExpandEnvironmentStringsW` 和 `SendMessageTimeoutW`）时，对 `unsafe` 代码块进行了详尽的 SAFETY 注释。
+  - 能够妥善处理 UTF-16 编码和解码，保留非法码点避免丢失路径信息，细节处理非常到位。
+
+### 3.2 命令行工具 (`cli`)
+- **原子性与并发安全**：
+  - 在 CLI 的 `verify_and_save` 逻辑中，写入前会重新读取注册表并与原始状态对比。如果不一致，则拒绝写入并报错退出。这有效地防止了并发情况下的配置覆盖问题。
+- **用户体验**：
+  - 命令设计符合直觉，支持 `--dry-run` 预览以及 JSON 格式输出，方便与其他脚本集成。
+
+## 4. 前端代码审查 (React + TypeScript)
+
+### 4.1 状态管理 (`app-store.ts`)
+- 使用 `Zustand` 进行全局状态管理，状态树设计合理，避免了 React Context 可能带来的不必要重渲染。
+- 实现了完善的 `UndoRedoManager`，将每一步操作抽象为 `OperationType`，支持撤销/重做功能，这对于编辑器类应用来说是核心体验的加分项。
+- `isSaving` 状态守卫有效防止了用户双击保存按钮引发的并发竞争。
+
+### 4.2 UI 与逻辑分离
+- 业务逻辑抽象到 `src/core` 目录下（如 `path-manager.ts`, `validation.ts`），UI 组件仅负责渲染和事件绑定。
+- `useAppActions.ts` 钩子巧妙地将组件层与 Store 状态操作解耦，使得组件代码极其整洁。
+
+## 5. 改进建议 (Recommendations)
+
+虽然当前代码质量已经很高，但仍有以下几个方面可以进一步优化：
+
+1. **Rust FFI 维护性**：
+   当前 `system.rs` 中手动声明了 `extern "system"` 函数。建议引入 `windows-rs` 或 `windows-sys` 库，这能提供微软官方维护的安全的 API 绑定，减少手动编写 FFI 签名带来的维护成本和潜在错误。
+2. **GUI 保存的并发安全 (Race Condition)**：
+   CLI 已经实现了保存前的二次状态比对（`verify_and_save`），但在 `gui/src/commands/registry.rs` 中，直接调用了 `save_system_paths`。如果在用户打开 GUI 修改期间，另一个进程修改了注册表，GUI 保存时可能会覆盖该修改。建议在 GUI 的 IPC 保存接口中，也引入类似 CLI 的版本校验（例如传入 `expected_original_paths` 进行比对）。
+3. **前端单元测试覆盖**：
+   核心逻辑如 `undo-redo.ts` 和 `path-manager.ts` 纯函数特性明显，建议在 `tests/unit/` 下增加对这些文件的边界用例测试，确保复杂编辑操作下状态不崩溃。
+4. **长列表性能**：
+   如果 PATH 环境变量条目非常多（虽然实际场景中一般在 100 条以内），React 渲染完整列表可能会有微小延迟。当前规模下无影响，但若未来考虑显示大量工具链路径扫描结果，可引入虚拟列表（Virtual List）。
+
+## 总结
+PathEditor v5.0 的代码库是一个优秀的 Rust + Tauri + React 实践范例。它具有清晰的三层架构、严格的类型和边界检查、以及良好的错误处理机制，整体架构稳健且易于长期维护。