组件库提供es、lib、dist三套CSS入口是为了适配不同构建环境：es供Vite等现代工具做tree-shaking和chunk分割，lib用于SSR/Jest等Node环境的CJS兼容，dist则面向CDN直引或Webpack传统配置，三者路径解析机制不同，必须严格匹配构建链路。
组件库为什么提供 es、lib、dist 三套 CSS 入口？
不是为了“多此一举”，而是为了匹配不同构建环境对模块系统和路径解析的处理差异。同一份样式代码，在 Vite、Webpack、CDN 直接引入、SSR 渲染等场景下，加载路径和解析方式完全不同，必须提供对应入口才能真正按需生效。
import 'xxx/es/button/style/css' 和 import 'xxx/dist/button.css' 区别在哪？
前者是 ESM 模块路径，后者是打包后产物路径；前者依赖构建工具做路径映射与代码分割，后者是静态文件直引，二者不能混用。
-
es/路径下是未编译的源码（含index.js+style/css.js），供现代构建工具（如 Vite）做 tree-shaking 和 chunk 分割 ——style/css.js里实际执行的是import '../style/index.css'，构建时能被识别并打到对应 JS chunk 中 -
dist/路径下是已编译的最终 CSS 文件（如button.css），适合 CDN 直引或 Webpack 传统配置，但无法参与按需拆包，容易导致样式冗余 - 漏掉
style/css.js中的import，只写import 'xxx/es/button'，样式根本不会进打包结果 —— 因为组件逻辑和样式在源码中是解耦的
为什么 lib/ 入口常被忽略但其实很关键？
lib/ 是 CJS 兼容入口，专为 Node 环境（如 SSR、Jest 测试、rollup-plugin-commonjs）设计。若你在服务端渲染中 import 组件却没配好 lib 样式路径，会出现“样式丢失但控制台无报错”的静默失败。
- Webpack 5+ 默认不解析
exports字段中的import条件，会 fallback 到main字段，而很多组件库的main指向lib/index.js - 此时若
lib/button.js内部没有require('../style/index.css')，或你没手动import 'xxx/lib/button/style'，样式就彻底不会加载 - Vite 开发模式下通常走
module或exports，所以lib不显性暴露问题；但一到 SSR 构建或测试环境，立刻暴露
CDN 场景下误用 es/ 路径会怎样？
直接用 https://unpkg.com/xxx@1.2.3/es/button/style/css.js 会 404 —— CDN 不提供源码级路径映射，只托管 dist/ 下的产物。
立即学习“前端免费学习笔记（深入）”；
- CDN 正确路径是
https://unpkg.com/xxx@1.2.3/dist/button.css（纯 CSS）或https://unpkg.com/xxx@1.2.3/dist/xxx.css（全量） - 某些库（如 Element Plus）提供
.css.js后缀的“伪模块”入口，本质是 UMD 包裹的 CSS 加载脚本，仅用于兼容旧构建流程，非标准 ESM - 用错路径最典型的表现：Network 面板看到 404，但页面没报错，样式空白 —— 因为 JS 加载失败，CSS
import根本没执行
es，Webpack 4 项目可能得切 lib，SSR 项目必须确认服务端是否能 resolve 到对应样式路径 —— 差一个斜杠、少一层 style/，样式就悄无声息地消失了。 
