SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场optimize

optimize

编程与开发

查看项目

更新于 10-16 04:08

技能介绍

用途

optimize 是一个代码优化技能，名称标识为 han-core:optimize，用于针对性能、可读性或效率对代码进行优化。其调用形式为 /optimize [arguments]。

该技能的核心原则是：测量，不要猜测。没有数据的优化就是猜测。其首要规则是：绝不在未测量的情况下进行优化。原因是过早优化会把时间浪费在非问题上，同时错过真正的问题。例外情况是：当存在 O(n) 替代方案时，明显的 O(n^2) 算法可以直接处理。

主要能力

该技能提供一套系统化的性能问题识别与修复方法，流程包括：

  1. 测量当前状态（基线）：在改动任何代码前建立指标。前端性能可使用 Chrome DevTools Performance 标签、Lighthouse 审计、npm run build && du -sh dist/ 查看包体积；后端性能可添加计时日志；数据库可使用 EXPLAIN ANALYZE SELECT ...; 或检查日志中的查询时间。需要捕获的指标包括加载时间/响应时间、可交互时间、包体积、内存使用、查询时长、渲染时间。

  2. 通过性能分析定位瓶颈：不猜测问题所在，而是进行性能分析。浏览器分析使用 Chrome DevTools 的 Performance 标签，记录交互，查找长任务（> 50ms），检查布局抖动。服务器分析可添加详细计时。React 分析使用 React DevTools Profiler，查找不必要的重渲染、慢组件（60fps 下超过 16ms）、过大的组件树。

  3. 识别根本原因：常见性能问题包括前端的大包体积、不必要的重渲染、阻塞式 JavaScript、未优化图片、过多网络请求、内存泄漏；后端的 N+1 查询、缺失数据库索引、循环中的昂贵计算、同步外部 API 调用、过大的 JSON 响应、低效算法；数据库的缺失索引、低效查询结构、过多连接、获取不必要列、无查询结果缓存。

  4. 应用针对性优化：一次只改一处，并测量每项改动的影响。前端优化包括包体积缩减（按需导入、使用原生替代方案）、React 性能（React.memo、useCallback）、代码分割（React.lazy 与 Suspense）、图片优化（响应式、懒加载）。后端优化包括修复 N+1 查询（预加载关联）、数据库索引、缓存、批处理。算法优化包括降低复杂度，例如将 O(n^2) 的嵌套循环改为使用 Set 的单次遍历 O(n)。

  5. 测量影响（工作证明）：优化后始终测量，记录优化前后的加载时间、包体积、可交互时间等对比数据，并可使用 proof-of-work 技能记录证据。

  6. 验证正确性：测试必须仍然通过，运行完整测试套件（如 npm test、mix test），并进行手动验证，确认功能仍可用、边界情况已处理、未引入新缺陷。

优化类型与目标

优化类型分为：性能（算法复杂度降低、数据库查询优化、缓存策略、懒加载与代码分割）、代码质量（简化与清晰、去除重复、更好的命名与结构、模式改进）、资源效率（内存使用降低、包体积优化、网络请求减少、资源优化）。

常见优化目标以清单形式给出。前端清单包括：包体积小于 200KB（gzip 后）、首次内容绘制小于 1.5s、可交互时间小于 3s、无布局偏移（CLS < 0.1）、图片已优化（WebP、懒加载）、按路由代码分割、移除未使用代码（tree shaking）、CSS 关键路径优化。后端清单包括：API 响应时间小于 200ms（p95）、数据库查询已优化（EXPLAIN ANALYZE）、无 N+1 查询、存在适当索引、昂贵操作已缓存、慢任务使用后台作业、已配置连接池、大数据集分页。数据库清单包括：频繁查询列上有索引、已审查查询执行计划、无全表扫描、适当使用 LIMIT、连接已优化（最小表优先）、统计信息最新（ANALYZE）。

优化模式与反模式

优化模式包括懒加载模式（按路由代码分割）、记忆化模式（useMemo 仅在数据变化时重新计算）、数据库查询优化模式（使用 join 和 preload 替代多次查询）。

反模式包括：优化错误的对象（应优化每次页面加载运行 10,000 次的函数，而非只运行一次的函数）；过早优化（应基于测量结果而非猜测）；微优化（应关注高影响优化，如减少 200KB 包体积以节省 1000ms，而非用 for 循环替换 .map() 节省 1ms）；为性能破坏功能（性能不应以正确性为代价）；无证据优化（应先测量、优化、再测量）。

需要权衡的取舍

性能与可读性：更可读的写法（filter 加 map）与更快的写法（单次循环）之间存在取舍，应先做性能分析再决定性能收益是否值得可读性损失。性能与可维护性：缓存增加复杂度，记忆化增加内存开销，代码分割增加包管理，应始终记录所做的取舍。

工具与命令

前端：npm run build -- --analyze 进行包分析；npx lighthouse https://example.com --view 进行 Lighthouse 审计；npx webpack-bundle-analyzer dist/stats.json 进行体积分析。后端：EXPLAIN ANALYZE SELECT ...; 进行数据库查询分析；使用 :eprof.start()、:eprof.profile(fn -> YourModule.function() end)、:eprof.stop() 分析 Elixir 代码。

输出格式

输出包括：当前状态（基线指标或问题）、分析（问题成因）、建议改动（具体优化项）、预期影响（预测改进）、验证（改进证明，使用 proof-of-work 技能）。

适用场景

当用户说“这个函数太慢了”“优化这个模块中的数据库查询”“减少这个组件的包体积”“让这段代码更可读”“这个页面加载时间太长”等时适用。

与其他技能的集成

使用 proof-of-work 技能记录测量结果；优化时使用 boy-scout-rule 技能（让代码比发现时更好）；使用 simplicity-principles 技能（更简单往往更快）；使用 code-review 技能验证优化质量。

限制与提醒

该技能强调：先测量，找到真正的瓶颈；一次只改一处，明确是什么起了作用；测量影响，验证改进；保持正确性，测试必须通过；记录取舍，解释原因。快速但错误的代码毫无用处，正确且足够快的代码才是完美的。