diff --git a/zhmd/v2.5.8.md b/zhmd/v2.5.8.md
index e7581cf..e7d309a 100644
--- a/zhmd/v2.5.8.md
+++ b/zhmd/v2.5.8.md
@@ -292,4 +292,17 @@ OK cache -> len=600 entries loaded
   这样加载器会判定它们无效，并在下次启动时从健康的源 LoRA 重新生成。
 - 没有任何源 LoRA 文件被修改或重新下载 —— 损坏仅限于*生成的*缓存产物。
 - 如果以后再次遇到这类崩溃（任何 safetensors mmap 加载），
-  同样适用「按字节读取」的修复模式。
\ No newline at end of file
+  同样适用「按字节读取」的修复模式。
+
+---
+
+## 7. LoRA 功能完全保留——这不是"禁用 LoRA"的修复
+
+本次修复**只改变了预编译缓存文件的读取方式**（基于 mmap 的 `load_file` → 普通字节读取 + `safetensors.load`）。它**不会**禁用、跳过、削弱或以任何方式改变 LoRA 的行为：
+
+- 两种读取路径解析的是完全相同的文件字节，因此每个融合后的 LoRA 权重（`A`、`B`、`alpha`）都以逐位相同的值加载。已用 `InStyle-0.5` 缓存实测：新旧读取路径下全部 **1200 个张量**完全一致（每个 key 都通过 `torch.equal`；无 dtype / shape / 值差异）。
+- 返回的 `processed_groups` 字典——也就是 `compose_loras_v2()` 实际用于应用 LoRA 的数据——与修复前完全一致。下游的 LoRA 注入 / modulation 逻辑完全未动。
+- **健康缓存**：加载行为完全相同，LoRA 结果完全相同。
+- **损坏缓存**：旧代码会让整个 ComfyUI 进程崩溃（Windows 致命 page error），根本*无法生成任何图片*；新代码则回退到从原始源 LoRA 完整重新融合，LoRA 仍会正确应用——融合结果还会作为健康缓存重新保存。
+
+简言之：本次修复让 LoRA 在所有场景下保持完整可用；它只是把致命崩溃变成了优雅恢复。