审查 .NET/C# 代码性能反模式并生成分级修复清单

当你需要系统扫描 C#/.NET 代码中的性能反模式（异步、内存、字符串、集合、LINQ、正则、序列化、I/O）并按严重程度给出可执行修复建议时使用。

适用场景

解决思路

1. 从包含本 SKILL.md 的目录（而非用户工作区）解析捆绑路径，优先加载 references/critical-patterns.md；若直接读取失败，只列出该技能的 references/ 目录一次，仅当列表中出现预期文件时才重试，不要用工作区文件或文本搜索来定位技能安装位置。
2. 扫描代码中的信号以确定要检查的模式类别，先用 critical 参考中的 ## Detection 段和 Step 3 的内联配方做初始信号检测。
3. 按扫描深度加载对应的主题参考文件：critical-only 只加载 critical-patterns.md；standard（默认）加载与检测到的信号匹配的参考（async-patterns.md、memory-and-strings.md、regex-patterns.md、collections-and-linq.md、io-and-serialization.md，以及始终加载的 structural-patterns.md）；comprehensive 加载全部六个主题参考。
4. 按信号选择主题：出现 async/await/Task/ValueTask 查异步模式；出现 Span</Memory</stackalloc/ArrayPool/string.Substring/.Replace(/.ToLower()/循环内 +=/params 查内存与字符串；出现 Regex/[GeneratedRegex]/Regex.Match/RegexOptions.Compiled 查正则；出现 Dictionary</List</.ToList()/.Where(/.Select()/LINQ 方法/static readonly Dictionary< 查集合与 LINQ；出现 JsonSerializer/HttpClient/Stream/FileStream 查 I/O 与序列化；无论信号如何都检查结构模式（未密封类）。
5. 若某个已选参考在重试后仍不可用，用 Step 3 的内联配方覆盖缺失部分，并在最终报告中加入：Reference coverage: reduced; unavailable: <paths>; used inline recipes for missing references.（<paths> 只填已选参考中缺失的相对路径）。
6. 对小于 500 行的文件先整文件通读，再用 grep 确认计数并捕捉可能遗漏的模式；对每个相关模式类别运行检测配方，报告精确计数而非估算。
7. 运行核心扫描配方：字符串与内存用 grep -n '\.IndexOf(\"' FILE、grep -n '\.Substring(' FILE、grep -En '\.(StartsWith|EndsWith|Contains)\s*\(' FILE、grep -n '\.ToLower()\|\.ToUpper()' FILE、grep -n '\.Replace(' FILE、grep -n 'params ' FILE；集合与 LINQ 用 grep -n '\.Select\|\.Where\|\.OrderBy\|\.GroupBy' FILE、grep -n '\.All\|\.Any' FILE、grep -n 'new Dictionary<\|new List<' FILE、grep -n 'static readonly Dictionary<' FILE；正则用 grep -n 'RegexOptions.Compiled' FILE、grep -n 'new Regex(' FILE、grep -n 'GeneratedRegex' FILE；结构用 grep -n 'public class \|internal class ' FILE、grep -n 'sealed class' FILE、grep -n ': IEquatable' FILE。
8. 扫描规则：对检测到的每个模式类别运行所有相关配方；在分类发现前先输出扫描执行清单，列出每个配方及其命中数；0 命中是有效且有价值的结果（确认良好实践）；若已加载参考文件，还要运行其 ## Detection 配方。
9. 应用 Verify-the-Inverse 规则：对缺失类模式始终统计两侧并报告比例（如“M 个类中有 N 个已密封”），比例决定严重程度——0/185 是系统性问题，12/15 是一致性修复。
10. 做跨文件一致性检查：若某文件发现已优化模式，检查同目录、同接口、同基类的兄弟文件是否使用未优化等价写法，若有则标为 🟡 Moderate 并以已优化文件为证据。
11. 做复合分配检查，捕捉单行配方遗漏的多重分配模式：跨多个 if/else 分支调用 .Replace() 的方法要报告所有分支的总分配数；跨方法链式调用（如 A 调用 B 做 3 次正则替换再调用 C）要作为一条发现报告整条链成本；形如 result += $"...{Foo().ToLower()}" 的复合 += 要标记复合成本而非只标 .ToLower()；区分资源加载的格式字符串（不可修复）与编译期字面量格式字符串（可用插值修复），并枚举可操作位置。
12. 为每条发现分配严重程度：🔴 Critical 为死锁、崩溃、安全漏洞、>10x 回归，必须修复；🟡 Moderate 为 2-10x 改进机会、热路径最佳实践，热路径上应修复；ℹ️ Info 为模式适用但代码可能不在热路径，若性能分析显示有影响再考虑。
13. 按优先级规则处理：若用户指明热路径代码，将该代码中所有发现提升到其最高严重程度；若热路径上下文未知，无条件报告 🔴 Critical 发现，🟡 Moderate 发现附注“若此代码在热路径上则有影响”；绝不对明显非性能敏感的代码建议微优化。
14. 按规模升级严重程度：同一反模式出现 1-10 处按基础严重程度报告；11-50 处将 ℹ️ Info 升级为 🟡 Moderate；50+ 处升级为 🟡 Moderate 并提高优先级，标记为代码库级系统性问题；始终报告精确计数而非估算或代理摘要。
15. 生成紧凑发现：每条发现一个短块，按严重程度（🔴 → 🟡 → ℹ️）分组而非按文件分组；格式为 #### ID. 标题 (N 处实例)、**Impact:** 一行影响说明、**Files:** file1.cs:L1, file2.cs:L2, ...（内联逗号分隔列表，不用表格）、**Fix:** 一行修改说明、**Caveat:** 仅在非显而易见时（版本要求、正确性风险）。
16. 紧凑输出规则：对琐碎修复（加关键字、参数或类型变更）不用 ❌/✅ 代码块，一行修复说明即可；仅对非显而易见的转换（如把 LINQ 链换成 foreach 循环、提升闭包）包含代码块；文件位置用 File.cs:L42 格式的内联逗号分隔列表而非表格；除 Impact 行外不写解释性文字；合并共享同一修复的相关发现（如所有 .ToLower() 调用合为一条发现，不按文件拆分）；正面发现用项目符号列表而非表格，每行一个模式：✅ 模式 — 证据。
17. 结尾附汇总表和免责声明：表格列为 Severity、Count、Top Issue，行含 🔴 Critical、🟡 Moderate、ℹ️ Info；免责声明说明结果由 AI 生成、非确定性，可能含误报、漏报或对具体上下文不正确的建议，应用前务必用基准测试和人工审查验证。
18. 交付前验证：所有 critical 模式已检查（来自参考文件或内联配方）；主题配方仅在检测到匹配信号时运行；每条发现包含具体代码修复；扫描执行清单完整（所有配方已运行）；结尾包含汇总表。
19. 避免常见陷阱：不要因每个 Dictionary 都标记需要 FrozenDictionary，仅当构造后从不修改时才标记；不要在异步方法中建议 Span<T>，异步代码用 Memory<T>，Span<T> 仅用于同步热路径；不要报告热路径之外的 LINQ，仅在已识别热路径或紧密循环中标记 LINQ，.NET 7 起 LINQ 的 Min/Max/Sum/Average 已向量化，全面禁用 LINQ 是误导；不要在应用代码中建议 ConfigureAwait(false)，它仅适用于库代码且主要不是性能问题；不要到处推荐 ValueTask，仅用于频繁同步完成的热路径；不要对 DI 服务中的 new HttpClient() 直接标记，先检查是否已使用 IHttpClientFactory；不要对动态模式建议 [GeneratedRegex]，仅当模式字符串是编译期字面量时才标记；不要广泛建议 CollectionsMarshal.AsSpan，仅用于有基准证据的超热路径，它会增加复杂性和脆弱性；不要为微优化建议 unsafe 代码，除绝对必要外避免 unsafe，安全替代如 Span<T>、安全上下文中的 stackalloc 和 ArrayPool 已覆盖绝大多数性能需求。

适用边界 · 注意事项

• 算法复杂度分析——本技能针对 API 使用模式，不针对算法设计
• 不在热路径上且无性能要求的代码——避免过早优化