@ohos-cpf/3rdloop 0.0.1 → 0.0.3

package/vendor/Server/Skills/rn-library-memory-leak-check/assets/REPORT_TEMPLATE.md

@@ -1,83 +1,85 @@
-# 内存泄露检视报告模板
-
-> 本模板定义 RN 鸿蒙化内存泄露检视报告的输出格式。报告中必须包含 `**综合评分：XX/100**` 格式且位于"综合评分"章节，确保可被 `_parseRNLibraryScore` 函数正确解析。
-
----
-
-## 报告模板
-
-```markdown
-# {repoName} 内存泄露检视报告
-
-## 一、检视概览
-
-| 字段 | 内容 |
-|------|------|
-| **仓库名称** | {repoName} |
-| **检视类型** | RN 鸿蒙化内存泄露检视 |
-| **检视时间** | {timestamp} |
-| **分析文件数（ArkTS层）** | {etsFileCount} |
-| **分析文件数（C/C++层）** | {cppFileCount} |
-
-## 二、综合评分
-
-**综合评分：{score}/100**
-
-> 评分等级：{level}。{levelDescription}
-
-### 扣分明细
-
-| 扣分项 | 数量 | 单项扣分 | 小计 |
-|--------|------|----------|------|
-| 致命问题 | {fatalCount} | -20 | {fatalTotal} |
-| 严重问题 | {majorCount} | -12 | {majorTotal} |
-| 中等问题 | {mediumCount} | -8 | {mediumTotal} |
-| 轻微问题 | {minorCount} | -5 | {minorTotal} |
-
-## 三、检视维度明细
-
-### 3.1 TurboModule/NativeModule 生命周期管理
-### 3.2 NativeComponent 生命周期管理
-### 3.3 RN Bridge 事件机制
-### 3.4 鸿蒙 API 事件订阅
-### 3.5 闭包与上下文泄露
-### 3.6 Map/Set 数据清理
-### 3.7 NAPI 引用管理
-### 3.8 TurboModule/JSI 绑定内存
-### 3.9 Native 内存分配释放
-
-## 四、泄露风险清单
-
-| # | 文件 | 行号 | 语言层 | 严重度 | 泄露类型 | 泄露描述 | 修复建议 |
-|---|------|------|--------|--------|----------|----------|----------|
-
-> **语言层**列标注：`ArkTS`（ETS/TS 层）、`C++`（Native 层）、`RN`（Bridge/TurboModule 层）、`跨语言`（多层交互）
-
-## 五、改进建议
-
-### 5.1 致命问题修复优先级
-### 5.2 严重问题修复建议
-### 5.3 通用改进方案
-```
-
----
-
-## 评分等级对照表
-
-| 分数区间 | 等级 | 说明 |
-|----------|------|------|
-| 95-100 分 | 优秀 | 资源管理完善，无任何泄露风险 |
-| 85-94 分 | 良好 | 仅存在少量轻微风险，无严重/致命问题 |
-| 70-84 分 | 一般 | 存在严重级别泄露，需针对性修复 |
-| 55-69 分 | 较差 | 存在致命级别泄露风险，内存安全受威胁 |
-| <55 分 | 严重不足 | 多个致命泄露问题，内存风险极高，不可发布 |
-
-> **严苛标准**：内存泄露不同于一般代码质量问题，一旦发生即造成持续损害。85 分以下即不建议发布，55 分以下视为严重不可用。
-
----
-
-## 注意事项
-
-- 泄露风险清单必须标注 **语言层**（ArkTS/C++/RN/跨语言）
-- 每条泄露记录包含足够的定位信息（文件路径+行号），便于后续 SKILL 参考和综合报告汇总
-- 综合评分格式必须为 `**综合评分：{score}/100**`，位于"综合评分"章节
+# 内存泄露检视报告模板
+
+> 本模板定义 RN 鸿蒙化内存泄露检视报告的输出格式。报告中必须包含 `**综合评分：XX/100**` 格式且位于"综合评分"章节，确保可被 `_parseRNLibraryScore` 函数正确解析。
+
+---
+
+## 报告模板
+
+```markdown
+# {repoName} 内存泄露检视报告
+
+## 一、检视概览
+
+| 字段 | 内容 |
+|------|------|
+| **仓库名称** | {repoName} |
+| **检视类型** | RN 鸿蒙化内存泄露检视 |
+| **检视时间** | {timestamp} |
+| **分析文件数（ArkTS层）** | {etsFileCount} |
+| **分析文件数（C/C++层）** | {cppFileCount} |
+
+## 二、综合评分
+
+**综合评分：{score}/100**
+
+> 评分等级：{level}。{levelDescription}
+
+### 扣分明细
+
+| 扣分项 | 数量 | 单项扣分 | 小计 |
+|--------|------|----------|------|
+| 致命问题 | {fatalCount} | -20 | {fatalTotal} |
+| 严重问题 | {majorCount} | -12 | {majorTotal} |
+| 中等问题 | {mediumCount} | -8 | {mediumTotal} |
+| 轻微问题 | {minorCount} | -5 | {minorTotal} |
+
+## 三、检视维度明细
+
+### 3.1 TurboModule/NativeModule 生命周期管理
+### 3.2 NativeComponent 生命周期管理
+### 3.3 RN Bridge 事件机制
+### 3.4 鸿蒙 API 事件订阅
+### 3.5 闭包与上下文泄露
+### 3.6 Map/Set 数据清理
+### 3.7 NAPI 引用管理
+### 3.8 TurboModule/JSI 绑定内存
+### 3.9 Native 内存分配释放
+
+## 四、泄露风险清单
+
+| # | 文件 | 行号 | 语言层 | 严重度 | 泄露类型 | 泄露描述 | 修复建议 |
+|---|------|------|--------|--------|----------|----------|----------|
+
+> **语言层**列标注：`ArkTS`（ETS/TS 层）、`C++`（Native 层）、`RN`（Bridge/TurboModule 层）、`跨语言`（多层交互）
+>
+> **严重度**列取值：`致命`/`严重`/`中等`/`轻微`/`观察（0 分）`。其中"**观察（0 分）**"用于记录对内存零影响的发现（如未接线的手写死代码、codegen 产物滞后、死代码单例设计隐患），须在"泄露描述"中注明不扣分理由（无内存影响），并在"修复建议"中指引归属阶段（编码质量/一致性检视），不计入扣分明细表。
+
+## 五、改进建议
+
+### 5.1 致命问题修复优先级
+### 5.2 严重问题修复建议
+### 5.3 通用改进方案
+```
+
+---
+
+## 评分等级对照表
+
+| 分数区间 | 等级 | 说明 |
+|----------|------|------|
+| 95-100 分 | 优秀 | 资源管理完善，无任何泄露风险 |
+| 85-94 分 | 良好 | 仅存在少量轻微风险，无严重/致命问题 |
+| 70-84 分 | 一般 | 存在严重级别泄露，需针对性修复 |
+| 55-69 分 | 较差 | 存在致命级别泄露风险，内存安全受威胁 |
+| <55 分 | 严重不足 | 多个致命泄露问题，内存风险极高，不可发布 |
+
+> **严苛标准**：内存泄露不同于一般代码质量问题，一旦发生即造成持续损害。85 分以下即不建议发布，55 分以下视为严重不可用。
+
+---
+
+## 注意事项
+
+- 泄露风险清单必须标注 **语言层**（ArkTS/C++/RN/跨语言）
+- 每条泄露记录包含足够的定位信息（文件路径+行号），便于后续 SKILL 参考和综合报告汇总
+- 综合评分格式必须为 `**综合评分：{score}/100**`，位于"综合评分"章节