用 React.lazy + Suspense 和…

当 Grafana 应用插件的 module.js 过大、初始加载慢时，通过懒加载与代码分割把入口文件压缩到 200KB 以内。

适用场景

解决思路

1. 在 CI 中加入 grafana/plugin-actions/bundle-size action，让每个 PR 自动获得包体积对比评论：根目录插件直接使用标准 workflow；子目录插件（如 monorepo 中的 plugin/）需自行安装依赖并把 plugin/yarn.lock、package.json、.yarnrc.yml、node_modules 软链接到仓库根目录，再给 action 传 working-directory: ./plugin。该 action 在 push 到 main 时构建并上传基线产物，在 PR 时对比并发表 diff 评论，可用 workflow_dispatch 生成首个基线。
2. 先检测插件上下文：用 jq -r '"\(.id) — \(.type)"' src/plugin.json 确认是 app 插件；用 ls src/module.ts src/module.tsx 定位入口；在改动前先跑 yarn build（或 npm run build）测量生产包体积，记录 dist/module.js 大小、dist/*.js 各 chunk 大小和 chunk 总数作为基线（未分割的插件 module.js 常在 1–3 MB 且无其他 JS chunk）。
3. 检查并更新 @grafana/create-plugin：查看 .config/.cprc.json 或 package.json 中的版本，用 npm view @grafana/create-plugin version 查最新版，执行 npx @grafana/create-plugin@latest update；更新后审查 diff（尤其 .config/webpack/webpack.config.ts）并跑一次测试构建，若插件有顶层 webpack.config.ts 做 webpack-merge，检查合并是否冲突。

适用边界 · 注意事项

• 不要改动 vendor 库（如 @grafana/scenes、@reduxjs/toolkit），webpack 会自动分割它们。
• 不要改动被大量文件共享的通用工具组件（如 Markdown、Spinner），改动面大且收益低，它们已在共享 vendor chunk 中。
• 拿不准时做到优先级 2 就停手——仅路由分割通常已能把 module.js 减少 95% 以上；不要为追求极致而过度分割。

经验正文