import cost 插件仅估算 import 行的 gzip 后体积，不控制打包体积；其显示 0 b 或 ? 是因静态分析路径中断，需改用 lodash-es 或明确路径如 lodash/debounce，并通过 import-cost.config.js 接入真实 webpack 配置以提升精度。
Import Cost 插件本身不控制打包体积，只估算 import 行可能带来的 gzip 后体积；它不改构建行为，也不影响最终产物——想真正瘦身，得靠 webpack 配置、导入方式调整和 tree-shaking 策略。
为什么 import { debounce } 一直显示 0 B 或 ?
这不是插件故障，是静态分析路径断了：插件看到 import { debounce } from 'lodash'，就去读 node_modules/lodash/package.json，但 v4 的 lodash 没标准 exports 字段，入口 index.js 又全是 export * from './xxx'，无法继续追踪。
- 临时解法：
import debounce from 'lodash/debounce'—— 路径明确，能读到真实文件及依赖 - 长期解法：换
lodash-es+ 开启 VSCode 设置Import Cost: Enable Typescript Support - 别指望改快捷键或重载插件能绕过这个限制——这是解析器能力边界，不是响应慢
怎么让 Import Cost 用上你的真实 webpack 配置
默认它走轻量静态分析，精度有限；要对接项目实际 resolve 规则（比如 alias、extensions、externals），就得显式接入 webpack。
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
- 在项目根目录建
import-cost.config.js，内容为：module.exports = { webpackConfigPath: './webpack.config.js' }; - 确保
webpack.config.js导出的是对象（不是函数），且能被require()直接加载（避免用__dirname或环境变量未定义导致报错） - 运行
npx import-cost .测试 CLI 是否能正常读取配置；如果报错，VSCode 插件也会静默失败
monorepo 里子包体积不显示？工作区路径没对
Import Cost 不会自动向上遍历找 webpack.config.js 或 package.json，它只认当前 VSCode 窗口的根目录。
- 推荐做法：在子包目录下单独打开一个 VSCode 窗口（不是整个 monorepo 根目录）
- 次选做法：在子包的
.vscode/settings.json里加："importCost.webpackConfigPath": "./webpack.config.js"
- 用 pnpm？确认
import-costCLI 版本 ≥ 3.0，否则workspace:协议解析会卡住
显示的 ~2.1 kB 到底准不准？别信“实时”，要看构建后
~ 符号不是装饰，是重要提示：它代表这是基于静态分析的估算值，不是真实构建产物。同一行 import，在 webpack-bundle-analyzer 页面里可能显示 5.1 kB（未 gzip）或 1.3 kB（gzip 后）。
- 验证路径：跑一次
npm run build→ 自动打开http://127.0.0.1:8888→ 对比 Import Cost 标注和真实扇形图 - 常见偏差点：
externals、CDN 引入、SplitChunksPlugin分包逻辑、TSpaths别名未被插件识别 - 最易被忽略的是：插件默认只显示 gzip 后体积，而构建报告常以 raw/minified 为主，单位混淆会导致误判
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
