使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
JavaScript内存泄漏不会直接报错，而是表现为内存持续增长、页面卡顿、GC频繁或OOM崩溃；需通过任务管理器观察内存阶梯式上升、DevTools对比快照找(detached)节点和重复闭包、检查未清除的事件监听器/定时器及5类危险代码模式来定位。
JavaScript 中内存泄漏本身**不会直接抛出报错**，它是一种“静默型”问题：没有 SyntaxError、TypeError 或其他运行时错误，而是表现为内存占用持续增长、页面变卡、GC 频繁但收效甚微，甚至最终 OOM 崩溃。所以所谓“常见报错”，其实是**排查过程中观察到的异常现象或 DevTools 中的可疑线索**，而非传统意义上的错误提示。 下面从实际可感知的信号出发，告诉你怎么一步步定位和解决：
看浏览器任务管理器确认泄漏是否存在
按 Shift + Esc 打开 Chrome 任务管理器，找到你的页面进程，持续观察 “内存” 和 “JS 堆” 列：
• 静置页面 30 秒以上，内存仍缓慢爬升 → 异常
• 反复执行同一操作（如打开/关闭弹窗）10 次，每次 JS 堆比前一次高 5–10MB 以上 → 极可能泄漏
• 内存曲线呈阶梯式上升、无回落 → 典型泄漏特征
用 Chrome DevTools 快速抓“嫌疑对象”
进入 Memory 面板，采用“三拍对比法”：
• 拍一张基准快照（页面刚加载完，静置）
• 执行疑似泄漏的操作（比如进组件、刷新列表、拖动地图）
• 拍第二张快照；再执行一次同样操作，拍第三张
• 点击第三张快照 → 在左上角选 Comparison → 对比“与第二张”的差异
重点关注：
• 类名带 (detached) 的 DOM 节点（已从文档移除但仍被 JS 引用）
• 大量重复出现的闭包函数（如 closure 或文件名+行号）
• 占用内存 Top 3 的构造函数（如 Array、Object、Map 实例激增）
查事件监听器和定时器这两类高频“真凶”
80% 的泄漏源于这两类未清理的引用，可直接在控制台验证：
• 输入 getEventListeners(document)，查看全局监听；切换路由后重输，比对是否新增未清除的 scroll、resize、click
• 搜索 window.performance.memory 查当前堆使用量，再执行 for (let i in window) { if (i.includes('timer') || i.includes('interval')) console.log(i) }，快速扫一遍可疑定时器变量
• React/Vue 项目重点检查：
– useEffect / onMounted 中启用了 setInterval 但没 return 清理函数
– addEventListener 后没配对 removeEventListener（尤其第三方库封装的）
代码中盯紧这 5 类危险模式
一旦锁定大致范围，回代码逐条核对：
• 未声明变量：函数内写了 data = []（漏了 let/const）→ 自动挂 window 上永不回收
• 闭包持大对象：返回的函数里引用了 const hugeList = new Array(1e6) → 整个数组锁死不释放
• DOM 引用残留：做了 el.remove()，但外面还有 let cachedEl = document.getElementById('x') → DOM 节点变成 detached 仍占内存
• 集合类无限增长：用 Map 缓存请求结果，但没设过期或清理机制 → key 越来越多，内存只增不减
• 第三方库副作用：地图、图表、富文本编辑器初始化后没调 destroy() → 内部监听器、canvas、数据结构全滞留
不复杂但容易忽略
