import cost插件不显示体积数字，大概率是未装好依赖或未识别打包器配置；它依赖webpack/rollup/esbuild配置估算体积，若配置缺失、路径错误或导出非标准对象，即显示“?”。
Import Cost插件为什么没显示体积数字
插件不显示体积，大概率是没装好依赖或没识别到打包器配置。它本身不计算体积，而是调用 import-cost CLI 工具，后者依赖项目里已有的 webpack、rollup 或 esbuild 配置来估算——如果项目没配打包器，或者配置文件（如 webpack.config.js）不在根目录、没被正确加载，插件就只能显示“?”。
实操建议：
- 确认项目根目录下存在有效的打包配置（
webpack.config.js、rollup.config.js或esbuild.config.js），且导出的是标准配置对象（不是函数式配置但未传入参数时可能失败） - 运行一次
npx import-cost .看是否报错，能快速暴露解析配置的问题 - VSCode 设置中检查
"importCost.enabled": true是否开启（默认开启，但有人会手动关掉） - 重启 VSCode，插件在打开文件时才初始化，热重载不触发重新探测
为什么 React / Lodash 的 import 显示体积远低于实际？
因为 import-cost 默认只做静态分析：它看的是你写了哪一行 import，再根据打包器配置里的 resolve.alias、externals、treeShaking 开关等推断“这一行最终打进包的代码量”，而不是真正跑构建。所以常见误判有：
-
import { debounce } from 'lodash'被当成全量引入（实际 Webpack + lodash-es 可以摇掉）→ 改用import debounce from 'lodash/debounce' -
import React from 'react'显示 20KB，但生产环境用了externals或 CDN → 插件不知道，照算源码体积 - TypeScript 项目没配
tsconfig.json的baseUrl和paths，导致别名路径解析失败，体积估算退化为 fallback 模式
如何让 Import Cost 支持 monorepo 子包的体积计算
monorepo 中子包往往有自己的 node_modules 和打包配置，但 VSCode 默认只认工作区根目录的配置。插件不会自动向上/向下遍历找配置文件。
实操建议：
- 在子包目录下打开 VSCode 窗口（而不是整个 monorepo 根目录），确保
webpack.config.js在当前窗口根路径 - 或者，在子包的
.vscode/settings.json中显式指定："importCost.webpackConfigPath": "./webpack.config.js"
- 若用 pnpm + workspace 协议，确认
import-costCLI 能正确解析link:或workspace:协议（v3.0+ 支持，旧版会卡在 resolve 阶段）
Import Cost 显示的数字单位是 KB 还是 B？怎么验证准确性
显示的是压缩后（gzip）的近似体积，单位是 KB，保留一位小数。它调用的是打包器的 stats 数据，不是原始源码大小。
验证方法很直接：
- 在终端运行
npm run build -- --stats-json（或对应命令），生成dist/stats.json - 用
source-map-explorer dist/main.js打开可视化分析，对比同一模块在图中的占比和 Import Cost 显示值 - 注意：如果插件显示 4.2KB，而
source-map-explorer里该模块占 3.8KB，属于合理误差范围（前者含 runtime + module wrapper 开销）
真正容易被忽略的是：它不反映运行时动态 import 的体积，也不处理 code split 后的 chunk id 冲突。看到 import('./foo').then(...) 旁边没数字？不是 bug，是设计如此。
