直接回答：组件库工程化五件事：产物形态（同时出 ESM 与 CJS，ESM 是 tree-shaking 的前提，package.json 的 exports 字段精确声明）、样式方案（CSS-in-JS 随组件走 vs 独立 CSS 文件，影响按需加载与主题能力）、文档与开发体验（Storybook/VitePress，示例即可交互的测试）、质量门禁（视觉回归测试、单测、类型声明）、版本与发布（changesets 语义化版本，破坏性变更走 codemod）。

展开解析：tree-shaking 的暗坑最多：package.json 必须标 sideEffects: false 或精确列出有副作用的文件（样式引入就是典型副作用文件，标错会导致样式被摇掉或整库失效）；组件间避免通过 index 桶文件互相引用造成隐式全量图；babel 转译别把 ESM 降级成 CJS（preset-env 的 modules: false）。样式按需两条路：CSS-in-JS（样式随 JS chunk 走，天然按需，但运行时成本与 SSR 复杂）与独立 CSS 按需插件（unplugin 类自动引入对应组件的 css），后者对主题定制与缓存更友好。视觉回归（Chromatic 或截图 diff）是组件库特有刚需——一个 padding 改动可能波及几百个使用方页面。生态兼容也要测：在 Vite/Webpack/Next.js 各起冒烟项目验证，消费者环境问题占组件库 issue 的大头。最后，组件库真正的成本在长期演进：API 设计前期多花十倍功夫，破坏性变更后期花一百倍代价。

追问方向：sideEffects 标错会怎样？如何为组件库写 codemod 辅助升级？

（约 480 字）