用途：在审查或修复 SwiftUI 性能问题时使用，以性能优先的思路审查代码，核心是「变更局部性」——说明哪个变更使 UI 的哪部分失效、为何代价高、如何让更新保持局部。
适用范围：SwiftUI 屏幕、列表、行、布局、绘制、动画与生命周期审查；以减少不必要更新或渲染工作为目标的定向重构；仅在用于验证 SwiftUI 性能假设时制定性能剖析计划。不适用于纯 UIKit 问题、启动性能（除非问题位于 SwiftUI 根视图或场景构建）、网络/后端/数据库/缓存（除非影响 SwiftUI 更新）、无 SwiftUI 代码路径的 Instruments 通用讲解，以及无具体性能风险的架构大改。
核心模型：先回答三个问题——什么变了？哪些视图依赖它？因此产生多少 UI 工作？随后检查标识（跨更新是否保留同一逻辑视图）、生命周期（状态是否由需要它的最小稳定组件持有）、依赖（每个视图是否只读取渲染所需数据）、渲染（body 是否轻量、可预测，无重型转换）、生命周期（异步工作是否绑定 .task、.onAppear 或显式动作，而非从 body 启动）。
审查流程：先看最小相关代码路径，顺序为标识稳定性、body 中的昂贵工作、过宽的状态或模型读取、状态归属与生命周期、列表与分页结构、闭包密集输入与自定义绑定及不必要类型擦除、重复内容中的布局绘制动画开销、异步生命周期与取消及主线程工作、必要时用性能剖析或调试探针确认。优先定向重构而非架构重写。
证据规则：必须区分静态代码审查发现、可能风险、假设、实测结果、用户提供的证据与工具产生的证据。除非用户提供证据或实际运行了剖析命令，不得编造耗时数字或声称剖析结果。
常见问题信号：不稳定 ID（如 .id(UUID())、var id: UUID { UUID() }）、可变集合用索引作标识、body 内排序/过滤/分组/格式化/解析/解码/数据库读取、在 ForEach 内过滤而非先备好可见行、把庞大模型传给每个子视图、掩盖大量状态读取的宽泛计算属性、大型重复集合中的 AnyView、可用 key-path 绑定时用自定义 Binding(get:set:)、行视图内存储大量非视觉闭包、每行使用 GeometryReader、preferences、重阴影、遮罩、模糊或覆盖层、直接从 body 启动异步工作、行内无保护的 .onAppear 分页触发。
重构准则：用最小修复对症——保持标识稳定；把昂贵转换移出 body；在重复渲染路径外准备可渲染模型；把状态移近持有它的组件；将大视图按依赖拆成子视图；简化行输入与重复结构；无需转换时优先 key-path 绑定；仅当视觉相等明确且比重新计算更便宜时才用 .equatable()；工作绑定变化输入并需自动取消重启时用 .task(id:)。不要把关。equatable()、记忆化或缓存当万能药，先解释失效或渲染问题。
回应格式：代码审查回复「主要问题、为何在 SwiftUI 中重要、风险等级、建议重构、必要时给代码示例、需确认时测什么」；剖析请求回复「场景、假设、工具或探针、看什么、如何前后对比」。限制：本技能未提供自身价格、平台或可用渠道信息；官方文档内容暂未提供。