CSS选型应坚持“够用、可控、可维护”原则：小项目用原生CSS，中大型项目再引入Sass或Tailwind；重调试友好性、source map、渐进迁移与设计令牌统一；团队需规范命名、体积监控和lint规则。
用CSS工具和框架，核心是“够用、可控、可维护”，不是堆功能或追新。选得不合适，反而拖慢开发、增加bug、让团队协作变难。
明确项目规模与长期维护需求
小项目或临时页面，直接写原生CSS更轻快；中大型项目才值得引入预处理器（如Sass）或框架（如Tailwind）。别为5页静态站配一套PostCSS+PurgeCSS+自定义设计系统——配置成本远超收益。
- 团队新人多？优先选语法直观、文档好、调试友好的方案（比如Sass比Less生态更稳，Tailwind比Bootstrap更易约束样式边界）
- 要长期迭代？确保工具支持source map、变量提取、主题切换等基础能力
- 已有遗留代码？先评估迁移成本，避免“重写式升级”——可逐步用@use导入Sass模块，或用utility-first方式渐进替换旧class
控制定制深度，避免过度封装
框架自带的按钮、卡片组件很省事，但一旦开始大量覆盖!important、深挖嵌套选择器、或写一堆“my-btn-v2-primary-large-disabled”类名，就等于自己造了一套难懂的方言。
- 用Tailwind？靠配置theme和plugins扩展，而不是写大量@layer components
- 用Bootstrap？删掉不用的SCSS模块（如carousel、tooltip），用bootstrap/scss/functions单独引入所需函数
- 自研UI库？把颜色、间距、圆角等基础值抽成设计令牌（design tokens），CSS变量或JS对象双端同步，别散落在几十个文件里
构建流程要透明，调试不能变黑盒
加了PostCSS插件、CSS-in-JS、原子化生成器之后，浏览器开发者工具里看到的class名可能和源码完全对不上，定位样式来源变困难。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
立即学习“前端免费学习笔记（深入）”；
- 开启source map并确保它真正生效（检查Network面板里的.css.map是否返回200）
- Tailwind用户：启用debugScreens或content路径配置准确，避免purge误删关键class
- 避免在构建后手动修改生成的CSS——所有样式变更必须可追溯到源文件
团队规范比工具本身更重要
再好的框架，如果没人统一命名、没人清理废弃class、没人review CSS体积增长，半年后照样变成样式泥潭。
- 约定BEM或类似命名法，哪怕用Tailwind也规定何时用，何时抽成.my-card-wrapper
- 把CSS体积监控接入CI（比如用size-limit检测单个组件CSS是否暴涨）
- 定期跑stylelint，规则聚焦在可读性上：no-duplicate-selectors、max-nesting-depth、selector-class-pattern
基本上就这些。工具是拐杖，不是腿。用得舒服的前提，是清楚自己想往哪儿走，以及谁会接着走这条路。
