CodeX：Angular项目性能优化实例分享

最近在尝试使用AI Agent优化项目，选用了性价比比较高的CodeX（咸鱼20元/月） 结合我自己在对话式AI方面的使用思路，分享一下我优化项目的完整流程。 AI模型： GPT 5.3 Codex ， 思考程度超高 注1 ：CodeX对话框里的文本我会用且只用引用来展示，例如： 请帮我写一个helloworld程序

文章 · Angular · 2026/04/16

最近在尝试使用AI Agent优化项目，选用了性价比比较高的CodeX（咸鱼20元/月）

结合我自己在对话式AI方面的使用思路，分享一下我优化项目的完整流程。

AI模型：GPT-5.3-Codex，思考程度超高

注1：CodeX对话框里的文本我会用且只用引用来展示，例如：

请帮我写一个helloworld程序

以下是这个程序的代码：

……

注2：由于项目是在虚拟机环境中运行，打包时间仅供参考（内存性能低）

分析项目结构，提取优化思路

我其实对于项目的优化思路是很清晰的，但是我希望AI能够帮我细化和补全，所以我”抛砖引玉“了一下

你是一位精通 Angular20、前端工程化、性能优化、构建优化和项目架构整理的高级前端工程师。

请先完整浏览我当前项目的结构、路由、页面组织方式、公共模块、共享组件、样式入口、构建配置以及主要依赖，然后只做分析和建议，不要直接修改代码，不要创建文件，不要删除文件，不要执行重构。

我希望你基于当前项目实际情况，重点从以下几个方向评估优化空间。

  1. 提升页面和组件的加载速度。
  2. 提升项目启动速度和打包速度。当前打包时间大约在60到90秒，我希望进一步缩短。
  3. 提升代码复用性，减少重复实现。
  4. 优化项目结构和整体逻辑，让后续维护更清晰。
  5. 补充你认为值得做、但我暂时没有想到的优化点。

执行要求如下。

  1. 先完整浏览项目，再输出结论，不要在还没看清结构前就直接下判断。
  2. 不要直接执行任何优化，只做梳理、分析和建议。
  3. 请结合项目中的真实情况给建议，不要只给通用型前端优化建议。
  4. 建议要尽量有优先级，不要杂乱罗列。
  5. 每一条建议单独列出，并简单说明：
    1. 当前问题是什么。
    2. 你准备怎么优化。
    3. 这样做主要能提升什么。
    4. 是否有改动风险或注意事项。
  6. 如果你发现某些问题影响特别大，请明确标注为高优先级。
  7. 如果项目中存在明显的性能瓶颈、结构问题、安全隐患、打包异常点或者不合理依赖，也请一起指出。
  8. 这一步只要给建议和思路，不要开始改代码。

最后请按下面格式输出。

  1. 你对当前项目现状的总体判断。
  2. 你发现的关键问题。
  3. 优化建议清单，按优先级从高到低逐条列出。
  4. 每条建议的简要做法和预期收益。
  5. 如果要真正落地，请再补充一个合理的分阶段实施顺序，但此时仍然不要执行。

AI在跑了差不多半个小时后给出的方案如下
我觉得整体还是没太大问题的。

我已经把项目结构和关键链路梳理了一遍，并做了实测构建分析（未改代码）。关键结论是：现在几乎所有业务页面都被打进了首包。

已确认的现状（依据）：

路由是静态聚合方式，app.routes 把各业务 ...Routes 直接展开（app.routes.ts）。
各业务 route 文件继续静态 import 组件并 component: 直连（如 planmanage.route.ts）。
生产构建实测约 60.8s，Initial total 6.67MB（raw），main 4.36MB；stats 在 stats.json。
main 中包含 286 个 pages ts 文件（基本等于全量业务页面）。
全局样式较重：全量引入 ng-zorro less（theme.less）。
TableShareModule 被大量页面复用且导出范围很大（table-share.ts）。
ConfigService 里有硬编码 baseUrl（config-service.ts）。
存在固定密钥（app.ts、login.ts）。
优化建议（按优先级，一个一个来）：

  1. 路由改为真正懒加载（目标1/2/4）：把顶层 children: [...xxxRoutes] 改成 loadChildren，把业务路由里的 component 改 loadComponent，先从低频模块开始拆。
  2. 重依赖按页面动态加载（目标1/2）：echarts/quill/html2canvas 不进首包；例如把 quality-report.ts 的 html2canvas 改为点击导出时 import()。
  3. ECharts 改为按需 core 版（目标1/2）：从 import * as echarts from 'echarts' 改为 echarts/core + 必需图表/组件注册，可明显降包体。
  4. 拆分 TableShareModule（目标1/3/4）：按“表格/表单/详情/上传/图表”拆成小共享模块，页面只引入需要的模块。
  5. 精简全局样式入口（目标1/2）：评估从全量 less 改为预编译 CSS 或按需主题，quill.snow.css 从全局移到富文本页面加载（styles.css）。
  6. 收紧图标资源策略（目标1/2）：当前 assets 复制了大量 ant icon 文件（angular.json assets 配置），改为“仅注册使用到的图标”或白名单拷贝。
  7. 建立字典数据缓存层（目标1/3）：供应商/渠道/品类 等下拉接口用 shareReplay + TTL 缓存，避免每页重复请求。
  8. 统一订阅释放与状态流（目标1/3/4）：逐步把手写 subscribe 改为 async pipe / takeUntilDestroyed，减少内存泄漏和重复副作用。
  9. 精简 App 根组件副作用（目标1/4）：合并 app.ts 和 app.ts 两套路由订阅，避免重复执行 checkUnread/checkDomainAndApi。
  10. 配置分环境治理（目标2/4）：引入 environment + fileReplacements，把 baseUrl/开关从业务服务中抽离。
  11. 减少 CommonJS 负担（目标1/2/3）：lodash 改 lodash-es 按函数引入，crypto-js 只引 AES 子集或逐步迁 Web Crypto。
  12. 建立性能护栏（目标2/5）：把 budget 从 10MB 收紧到可控阈值，并把 stats.json 分析接入 CI，防止回归。
  13. 强化可复用与类型化（目标3/4）：服务层从 Observable/any 迁移到 DTO 接口，抽公共“查询表单+表格+导出”模板。
  14. 补齐自动化保障（目标5）：目前 spec 很少，建议先加“路由懒加载 smoke test + 核心页面渲染测试 + 关键接口契约测试”。

    15. 如果你愿意，我下一步可以给你一份“分三阶段落地顺序（每阶段改哪些文件、预期收益、风险点）”的实施清单。

    其中我对于我不太清楚不太熟悉的点进行了进一步询问
    最终确定了1-7、9-11方案，并让AI生成了一份优化清单：

    分阶段落地顺序清单（仅含 1-7、9-11）

    阶段1：底座整理（1-2天）
    覆盖：#10 #9
    动作：先做 environment 分环境配置，移除 ConfigService 硬编码地址；合并 App 里重复的路由事件订阅与重复副作用调用。
    验收：功能无回归，开发/测试/生产环境切换正常，首页初始化逻辑不重复执行。

    阶段2：路由拆包（2-4天）
    覆盖：#1
    动作：顶层路由改 loadChildren，业务路由改 loadComponent/loadChildren，先拆 planmanage/purchase/mic 这类大模块。
    验收：首屏只加载壳层和当前模块代码，非当前业务页不进首包。

    阶段3：重依赖延迟加载（2-3天）
    覆盖：#2 #3
    动作：把 echarts/quill/html2canvas 从静态引入改成页面或操作触发时动态引入；ECharts 切到 echarts/core 按需注册图表与组件。
    验收：main 和大公共 chunk 明显下降，图表页/富文本页按需加载正常。

    阶段4：样式与图标瘦身（1-2天）
    覆盖：#5 #6
    动作：减少全局样式入口负担（尤其全量 zorro less、全局 quill 样式）；图标资源改白名单策略，仅保留实际使用图标。
    验收：styles 体积下降，assets 文件数和体积下降，UI 外观保持一致。

    阶段5：复用与结构优化（3-5天）
    覆盖：#4 #7
    动作：拆分 TableShareModule/DetailShareModule 为小粒度共享模块；新增字典/下拉统一缓存服务（供应商、渠道、品类等）。
    验收：页面 import 更精简，重复请求减少，公共逻辑集中。

    阶段6：依赖治理收尾（1-2天）
    覆盖：#11
    动作：lodash 改按函数引入（或 lodash-es），crypto-js 仅保留必要能力或替换到更轻方案。
    验收：CommonJS 依赖影响下降，包体与构建时间进一步收敛。

    我觉得没什么问题，就直接开始了阶段一优化

    阶段一：底座整理，合并事件订阅

    阶段一的具体优化为

    阶段1已完成，已按你确认的范围先落地了两项核心优化（对应我们清单里的 #9、#10）：

    1. 配置环境化（去硬编码）

      • 新增环境文件并接入开发环境替换：

        environment.ts

        environment.development.ts

        environment.model.ts

      • 在 angular.json 增加 development 的 fileReplacements

      • config-service.ts 改为从 environment 读取 apiBaseUrl/imgBaseUrl

    2. 根组件路由订阅去重与逻辑收敛

      • app.ts 合并重复的 router.events 监听，统一到 handleNavigationEnd 处理，减少重复执行和维护成本

      • 域名/API 映射、旧系统跳转、测试环境判断等常量改为环境配置读取

    3. 顺手消除少量图片域名硬编码（提升复用性）

      • dialog-form.ts

      • package-info-archives.ts

      • trademark-packing-detail.ts

    验证结果：

    npm run build（生产构建）通过
    npx ng build --configuration development（开发构建）通过

    其中因为修改了打包环境，测试环境和生产环境的运行逻辑变了，通过进一步确认

    我之后将会摒弃较为麻烦的“注释/启动测试API或生产API”来切换测试区和正式区

    而是通过指令进行环境切换，例如：

    npm run start:test -运行测试环境，也可写作npm run st
npm run start:prod -运行正式环境，也可写作npm run sp
npm run build:test -打包测试环境，也可写作npm run bt
npm run build:prod -打包正式环境，也可写作npm run bp

    然后我让AI使用命令进行性能测试，将优化前后的差距用数值显现出来：

    指标 优化前 优化后 变化
    Initial total（Raw） 6.67 MB 2.31 MB -65.37%
    Initial transfer（估算） 1.18 MB 454.25 kB -61.50%
    main chunk（Raw） 4.36 MB 13.96 kB -99.69%
    构建耗时（production） 105.948 s 104.860 s（多次波动 85~105s） 无稳定显著下降

    阶段二：路由拆包，实现懒加载

    已完成，这一步我把“所有父模块路由”都做了懒加载优化。

    1. 顶层父路由（一级）

      • 已全部使用 loadChildren：app.routes.ts

    2. 各业务模块子路由（二级页面）

      • 已把 component: Xxx 全量改为 loadComponent（按页面懒加载）。

      • 这次共转换 233 处 loadComponent。

      • 关键改动覆盖文件（全部已改）：

        aftersales.route.ts

        business.route.ts

        channelmanage.route.ts

        customer-service.route.ts

        dashboard.route.ts

        devmanage.route.ts

        login.route.ts

        logisticsplan.route.ts

        mic.route.ts

        planmanage.route.ts

        productionmanage.route.ts

        project.route.ts

        purchase.route.ts

        sales.route.ts

        sales-analysis.route.ts

        supplier.route.ts

        systemauth.route.ts

        tools.route.ts

        transfer.route.ts

        vip.route.ts

        warehousing.route.ts

    3. 构建验证

      • npx ng build --configuration development 通过

      • npm run build 通过

    4. 效果说明

      • 首屏资源继续保持轻量（生产构建 Initial total 约 2.31MB）。

      • 懒加载粒度进一步细化为“页面级”，进入某业务模块时不再一次性拉整包页面。

      • 打包耗时不一定显著下降（这类改造主要提升运行时加载体验，不是主要加速构建时间）。

    路由方面的优化不会体现在打包中，而是系统的实际运行环境，所以我自己简单测试了一下优化前后的区别：

    指标 优化前 优化后
    初次加载页面体感速度 2-4s 1s内
    LCP（最大内容绘制） 4.79s 2.38s

    阶段三：npm包重依赖延迟加载

    这一步其实跟懒加载有点相似，但是实现方式有区别。

    js包使用的时候便调用并下载，没有使用的时候就完全不引入，可以降低打包体积、提升打包速度。

    阶段三已继续并完成，我把“优化前/后”都做了同机同环境采样，并保留了对比数据文件。

    本次已落地

    1. echarts 静态导入改为按需加载（含 provider 和 echarts.init 场景）。
    2. html2canvas 改为函数内动态 import()，仅导出/截图时加载。
    3. 移除 crypto-js 运行时静态依赖，改为轻量实现，并补了解密失败兜底解析。
    4. 去掉全局 provideQuillConfig，避免把 ngx-quill 挤进首包。
    5. GeneralService 去掉 date-fns 依赖，改为本地日期格式化。
    6. app/config/auth/general 增加 JSON 安全解析，避免 decrypt 失败直接崩。

    优化前后的结果如下：

    对比：

    • Initial total：2.31 MB -> 2.21 MB，减少 105,056 bytes（-4.54%）
    • Estimated transfer：454.25 kB -> 424.37 kB，减少 29.88 kB（-6.58%）
    • main chunk：13.96 kB -> 13.75 kB，减少 0.21 kB（-1.50%）
    • 构建耗时：59.377s -> 57.275s，减少 2.102s（-3.54%）

    依赖级证据（首包）：

    • crypto-js: 71,082 -> 0 bytes
    • date-fns: 20,026 -> 0 bytes
    • ngx-quill: 13,563 -> 0 bytes

    页面级证据：

    • quality-report 入口 chunk：221,682 -> 18,303 bytes（-91.74%）
    • 新增独立 html2canvas chunk：203,117 bytes（仅触发截图/导出时下载）

    构建耗时这个有点牵强了，毕竟2秒属于常规误差内，但打包体积，确实是明显下降了。

    阶段四：样式与图标瘦身

    在项目初步阶段的时候，因为ng-zorro的配置问题我是静态导入了所有图标，包括了没有使用的。

    所以这一步优化重点在于删除未使用过的图标，以及未使用过的样式：

    “样式与图标瘦身”这一步我已经继续做完并通过构建验证。

    已落地改动

    1. 图标资产从全量拷贝改为仅拷贝 svg（去掉无用 js 资产）

    2. quill.snow.css 从全局移除，改为富文本页面按需运行时注入

    3. 清理了一个未使用的 QuillModule 引用（limited-time-detail.ts）

    关键文件：

    • angular.json
    • styles.css
    • quill-style-loader.ts
    • supplier-enquiry-detail.ts
    • goods-bom.ts
    • blog-detail.ts
    • limited-time-detail.ts

    优化前后对比

    这一步的体积变化（前后对比）

    • styles：655.99 kB -> 631.75 kB（减少 24.24 kB）
    • Initial total：2.21 MB -> 2.18 MB（约减少 0.03 MB）
    • Estimated transfer：424.30 kB -> 421.34 kB（减少 2.96 kB）
    • dist/.../assets 文件数：1672 -> 838（减少 834，-49.88%）
    • dist/.../assets 总大小：2,213,587 -> 1,534,277 bytes（减少 679,310 bytes，-30.69%）

    阶段五：复用与结构优化

    这一步是为了优化代码结构，将页面完全相同的代码和逻辑提取出来作为一个公共写法。

    然而AI的优化方案虽然可行，但在优化过程中幻觉逐步增强，开始出现不存在的写法、没必要的写法、更复杂的写法。

    这一步的本质是提升代码复用性，将公共代码提取出来，用更少的代码实现更多的相似逻辑，然而修改前后代码量几乎没变，甚至写法更复杂，易读性更差了。

    于是在进行三次之后我回滚了代码，准备在后续编写一套完整的提示词和优化方案去实现。

    并且代码复用主要提升的是开发规范和逻辑，对于性能提升较小。

    阶段六：依赖治理收尾和检查

    已完成这轮“依赖治理收尾”并产出报告。

    执行结果

    lodash：已将整包导入改为按函数路径导入（lodash/toInteger、lodash/clone、lodash/size）。
    crypto-js：已从依赖中移除 crypto-js 与 @types/crypto-js。
    已完成构建与编码校验：
    npx ng build --configuration development 通过
    npx ng build --configuration production --stats-json 通过
    npm run check:encoding 通过（UTF-8 无 BOM）
    数据对比（优化前 vs 优化后）

    lodash 整包导入数：11 -> 0

    lodash 按函数导入数：0 -> 12

    crypto-js 直接依赖数：1 -> 0

    crypto-js 代码引用数：0 -> 0

    CommonJS 警告数：0 -> 0

    开发构建耗时：67.561s -> 65.538s（约 -2.99%）

    生产构建耗时：

    优化前：82.343s
    优化后多次：99.021s / 90.986s / 84.794s / 84.932s
    后两次稳定均值：84.863s
    生产初始包体：2.18 MB -> 2.18 MB

    生产初始传输体积：421.64 kB -> 421.62 kB

    对于打包的时长以及体积没有明显变化，但或许在未来引入包变多、变杂之后会有一定提升。

    阶段七：保留懒加载 + 主动预取（hover/idle 预加载）

    CodeX所做的懒加载优化，只有最普通的懒加载，虽然首屏速度加快了，但每次需要进入页面的时候点击一下都会有明显的卡顿，所以我还想再做一个主动预取。

    又因为我们的ERP系统因为每个人的菜单会根据权限实时变化，如果优先加载用户已有的菜单，会比直接全局主动预取更加有优势。

    你是一位精通 Angular20与ERP系统的高级前端工程师。

    在当前 Angular20 项目中实现保留懒加载加主动预取。

    要求如下。

    1. 保留现有 lazy load，不改成全量加载。
    2. 增加 idle 预取，进入系统后空闲时自动预取未加载页面。
    3. 增加 hover 预取，鼠标移入菜单项时预取对应页面。
    4. 优先只预取当前权限内菜单页面。
    5. 权限判断结合现有 getViewedMenuList 相关逻辑处理。
    6. 如果当前结构无法做到权限限定预取，就退化为全局主动预取，并说明原因。
    7. 处理好退出登录和切换账号后的预取状态重置。
    8. 最小改动实现，不要重构无关代码。

    最后只输出：

    1. 实现结果。
    2. 修改文件。
    3. 关键点。
    4. 验证情况。

    CodeX的输出结果

    已完成，实现结果是：

    保留现有懒加载不变。
    新增“主动预取”两种触发：
    idle 触发：进入系统后空闲时自动预取。
    hover 触发：鼠标移到菜单项时提前预取对应模块。
    实现了“仅预取权限内菜单页面”：
    预取权限来源于登录后已过滤的 navigation（即你当前账号可见菜单）。
    只会把这些菜单 URL 的父路由前缀加入预取白名单。
    非权限菜单不会被主动预取。
    兜底：若权限列表异常为空，则回退为全量预取（避免功能失效）。
    改动文件

    src/app/services/permission-aware-preloading.strategy.ts
    src/app/app.config.ts
    src/app/app.ts
    src/app/app.html
    关键点

    withPreloading(PermissionAwarePreloadingStrategy) 已接入路由。
    loadUserAndMenuData() 后同步权限菜单到预取策略。
    菜单链接增加 (mouseenter)="onMenuLinkHover(chil)"。
    退出登录会重置预取状态，避免不同账号权限串用。
    验证结果

    npx ng build --configuration development 构建通过。
    npm run check:encoding 通过（UTF-8 无 BOM）。

    进入项目，确认实现了懒加载+主动预取。

    最终阶段：全量验收、风险排查与优化收尾

    这一阶段就没有必要继续大改代码了，我想做的优化基本都完成了。

    所以这一步的核心目标不是“继续优化”，而是确认前面做过的优化有没有留下问题、有没有回归、有没有遗漏，以及现在这个项目到底处于什么状态。

    你是一位精通 Angular20、前端性能优化、工程化治理、回归检查和项目收尾验收的高级前端工程师。

    当前项目已经完成了多轮优化，我现在不希望你继续盲目新增优化，而是希望你站在“最后阶段收尾检查”的角度，对整个项目做一次系统性的验收、排查和总结。

    本轮的目标不是继续大改代码，而是确认以下事情。

    1. 之前已经完成的优化是否真实生效。
    2. 这些优化有没有带来功能回归、结构混乱、潜在 bug 或隐藏风险。
    3. 当前项目是否还存在明显可以顺手收尾的小问题。
    4. 整个优化过程是否已经达到一个适合暂时收尾的状态。

    你需要重点检查我已经完成的这些阶段。

    1. 阶段一，环境配置治理和根组件副作用整理。
    2. 阶段二，路由拆包和页面级懒加载。
    3. 阶段三，重依赖延迟加载和部分依赖轻量化。
    4. 阶段四，样式与图标瘦身。
    5. 阶段六，依赖治理收尾。
    6. 阶段七，保留懒加载加主动预取。
    7. 阶段五已经回滚，不纳入本次已完成优化验收，但如果你发现和它相关的残留问题，也请指出。

    请你先完整浏览当前项目，再重点从下面这些方面进行检查。

    1. 功能回归检查。
      检查环境切换、登录流程、菜单权限、路由跳转、页面打开、懒加载、主动预取、退出登录后的状态重置等关键链路是否存在明显问题。
    2. 路由与预加载检查。
      检查所有路由是否仍然正确可达，是否存在 loadChildren 或 loadComponent 写法错误，是否有懒加载失效、预取范围异常、权限菜单和预取白名单不一致的问题。
    3. 构建与配置检查。
      检查 angular.json、环境文件、npm scripts、构建配置、assets、styles、fileReplacements 是否存在遗漏、重复、错误或不合理配置。
    4. 依赖与导入检查。
      检查是否还存在不必要的整包导入、未清理的旧依赖、无效依赖、重复依赖、CommonJS 风险、动态 import 使用不合理、未被使用的代码或文件。
    5. 性能结果合理性检查。
      结合当前项目结构，判断前面这些优化结果是否合理，是否还存在明显拖慢加载、首包、构建或运行时体验的问题。如果有，请指出最值得补的一两项，但不要直接执行。
    6. 安全性和稳健性检查。
      检查是否还存在硬编码地址、固定密钥、危险的 JSON.parse、脆弱的本地存储读取、缺少兜底逻辑、容易因为异常数据导致崩溃的代码。
    7. 可维护性检查。
      检查当前优化后是否引入了新的复杂度，比如命名混乱、逻辑分散、重复封装、写法不统一、存在“能跑但后续难维护”的地方。
    8. 收尾清理检查。
      检查是否存在可以顺手处理的小尾巴，例如未使用 import、未使用文件、临时测试代码、失效注释、过期兼容写法、无意义日志、优化后遗留的旧逻辑。

    执行要求如下。

    1. 这一轮以检查、验证、总结为主，不要默认直接大范围改代码。
    2. 如果发现特别明显且风险很低的小问题，可以单独列出来，但先不要直接修改。
    3. 不要给空泛建议，要结合当前项目真实文件和真实结构来判断。
    4. 请尽量明确指出问题归属到哪一类。
    5. 如果某一项你无法完全确认，请明确说明“不确定，需要手工验证”。
    6. 不要为了凑结果而硬找问题，没有问题就直接说明通过。
    7. 这一步的重点是验收和收尾，不是继续发散式重构。

    最后请只输出以下内容。

    1. 当前项目整体状态判断。
    2. 已完成优化项的验收结果。
    3. 发现的问题清单。
    4. 其中哪些是高优先级风险，哪些只是收尾建议。
    5. 还需要手工验证的项目。
    6. 是否建议现在作为一个阶段性收尾版本结束。
    7. 如果还要继续，只推荐下一步最值得做的1到3项，不要展开执行。

    CodeX的返回结果如下，还是很完整的了：

    当前项目整体状态判断

    1. 当前版本已经具备“阶段性收尾候选”条件：懒加载、按路由拆包、重依赖延迟加载、环境切换脚本、编码检查都在工作。
    2. 但还存在 4 个高优先级风险，建议先处理后再作为正式收尾版本冻结。

    已完成优化项的验收结果

    1. 阶段一（环境配置治理、根组件副作用整理）: 部分通过。
    2. 环境切换配置有效（package.json:10、package.json:13、angular.json:72、angular.json:79、config-service.ts:28），但根组件仍有较重副作用和安全隐患（见问题清单）。
    3. 阶段二（路由拆包、页面懒加载）: 通过。
    4. 顶层 loadChildren + 子路由 loadComponent 已落地（app.routes.ts:5）。生产构建出现大量 lazy chunk（281+），说明懒加载生效。
    5. 阶段三（重依赖延迟加载）: 通过。
    6. html2canvas 已动态导入（如 quality-report.ts:211），echarts 采用延迟加载方案，Quill 样式按需注入（quill-style-loader.ts:1）。
    7. 阶段四（样式与图标瘦身）: 部分通过。
    8. 图标注册已精简（icons-provider.ts:8）。生产构建首包约 2.19 MB（estimated transfer 422.27 kB），但样式 chunk 仍较大（631.75 kB raw），需持续观察。
    9. 阶段六（依赖治理收尾）: 部分通过。
    10. lodash 已按函数路径引入，crypto-js 已移除代码使用；但依赖声明存在风险（见高优先级问题 #3）。历史数据见 dep_governance_report.json。
    11. 阶段七（懒加载 + 主动预取）: 部分通过。
    12. 已接入自定义预加载策略（app.config.ts:33）、hover/idle 触发（app.ts:516、app.ts:583、app.html:49），并在登出时重置（app.ts:347）。但权限为空时会回退为全量预取（见问题 #5）。

    发现的问题清单

    1. 高: 菜单权限过滤直接修改全局导航对象，存在跨会话/跨账号菜单污染风险。 app.ts:316、app.ts:321

    2. 高: 菜单存在可见但无路由的页面，测试环境可能点不进去（/sale/taobao-refund）。

      navigation.ts:770、sales.route.ts:4

    3. 高: 项目源码使用 lodash/*，但 lodash 未在 dependencies 声明，当前依赖于 karma 的传递依赖，构建可复现性有风险。 package.json:25、production-plan-detail.ts:4

    4. 高: 安全性风险，存在硬编码固定密钥与 postMessage('*')。 app.ts:135、app.ts:174、app.ts:204

    5. 中: 预加载策略在权限列表为空时会全量预取，不完全符合“仅权限菜单预取”。 permission-aware-preloading.strategy.ts:36

    6. 中: isPassGuard 存储介质不一致（写 session，读 local），逻辑有歧义。 app.ts:145、auth.guard.ts:37

    7. 中: 本地环境白名单仅写死 localhost:4200，换端口本地调试有潜在误判。 app.ts:547

    8. 中: 存储读取存在未兜底 JSON.parse，异常数据可导致运行时报错。 storage.service.ts:48、config-service.ts:294

    9. 低: 配置和入口存在重复/未使用 provider 与 import，增加维护噪音。 app.config.ts:40、app.config.ts:41、main.ts:1

    10. 低: allowedCommonJsDependencies 有陈旧项（如 crypto-js、quill-delta）angular.json:45

    11. 低: 阶段五虽回滚 ListPageBase，但仍有 TypedListPageBase 残留（需确认是否保留）。 typed-list-page-base.ts:1、vip-activity.ts:8

    12. 低: 调试日志较多（扫描到 109 处），建议收敛。

    其中哪些是高优先级风险，哪些只是收尾建议

    1. 高优先级风险: #1 全局导航被修改、#2 菜单路由不一致、#3 lodash 依赖声明缺失、#4 密钥与跨域消息安全。
    2. 收尾建议: #5~#12（预加载边界、存储健壮性、配置清理、日志清理、阶段五残留确认）。

    还需要手工验证的项目

    1. 权限预取是否严格只触发权限内模块网络请求（不确定，需要手工验证）。
    2. 图标精简后是否存在缺图/闪烁（不确定，需要手工验证）。
    3. npm run sp 启动时是否仍出现 Prebundling/HMR 警告（不确定，需要手工验证）。
    4. 旧系统登录透传链路（postMessage）在真实域名下是否稳定（不确定，需要手工验证）。
    5. 中文文案显示是否有乱码（控制台与文件读取存在编码显示差异，不确定，需要手工验证）。

    是否建议现在作为一个阶段性收尾版本结束

    1. 建议“先不结束最终收尾”，可以先作为 RC（候选收尾版本）。
    2. 先处理高优先级 4 项，再收尾更稳妥。

    如果还要继续，只推荐下一步最值得做的1到3项

    1. 修复菜单与路由一致性 + 导航过滤改为不可变处理（解决 #1 #2）。
    2. 补齐依赖声明与 CommonJS 白名单清理（优先处理 lodash 声明问题，解决 #3）。
    3. 做一轮安全加固（移除固定密钥、收紧 postMessage 目标源与存储解析兜底，解决 #4 #8）。

    由于业务逻辑方面的更改，其中部分风险是我已知且合理的，所以我选择让他处理第三点作为最终收尾。

    已只处理你指定的第 3 点，且未改业务代码。

    已将 lodash 补为显式运行时依赖：
    package.json:41
    锁文件已同步更新：
    package-lock.json:26
    验证结果：

    npm ls lodash --depth=0 现在为顶层依赖：lodash@4.18.1
    npx ng build --configuration development 构建通过
    说明：

    production-plan-detail.ts 等 lodash/* 引用无需改动，这次只修复依赖可复现性问题。