flex适用于一维布局，grid适用于二维布局；class命名应语义化、可复用；状态用data属性控制；媒体查询应基于内容密度而非设备尺寸。
为什么 flexbox 和 grid 不能混着“猜”着用
很多项目里布局错乱，不是因为写错了语法，而是把 flex 当成万能胶水，硬套在本该用 grid 的场景里。比如用 display: flex 去对齐一个二维表格结构的卡片列表，结果 flex-wrap 一换断点、justify-content 一调就塌；而同样结构，用 display: grid 配 grid-template-columns: repeat(auto-fill, minmax(280px, 1fr))，响应式和对齐天然解耦。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 一维排列（行或列）→ 优先
flex：导航栏、按钮组、表单控件流 - 二维网格（行列都要控制）→ 直接上
grid：仪表盘、商品列表、后台数据表格 - 别在
flex容器里再嵌一层flex去模拟格子——那是grid的职责，强行套只会让gap、align-items、justify-content互相打架
class 命名不是写作文，是建索引
看到 header-left-top-section 这种命名，基本可以判定后续改版时没人敢动它——太具体，一改就崩。CSS 不是描述“它长什么样”，而是表达“它是什么角色”。比如一个按钮，在不同页面都叫 btn-primary，但它的 padding、font-size 其实由所在上下文（如 .card__actions 或 .modal-footer）决定，而不是靠一堆修饰类堆砌。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 组件级 class 用 BEM，但只到
block__element，别加--modifier后缀去控制尺寸/颜色——那些交给 CSS 自定义属性或父容器 scope 控制 - 避免语义模糊的命名：
big-box、left-side、new-style——它们无法被复用，也经不起设计迭代 - 把视觉变量抽成
:root变量：--spacing-sm、--color-brand，而不是在每个 class 里写死margin: 8px
伪类和属性选择器不是装饰品，是逻辑开关
很多人只用 :hover 和 :focus 做交互反馈，却忽略 :is()、:where()、[data-status="loading"] 这些才是真正连接 HTML 结构与样式状态的枢纽。比如一个加载中的按钮，与其写 .btn.loading 再 JS 切 class，不如直接监听 button[disabled][data-loading]，用 CSS 控制 opacity 和 cursor，JS 只管数据，不碰样式状态。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
[data-*]属性代替大量状态类：data-invalid、data-expanded、data-size="lg"，比.is-invalid更易维护、更利于 SSR -
:is()替代重复选择器：比如:is(h1, h2, h3) + p比写三遍简洁，且不影响 specificity - 慎用
:nth-child()做业务逻辑——它依赖 DOM 顺序，一旦插入广告位或埋点节点就失效；改用:nth-of-type()或直接加 class 控制
媒体查询不是“适配手机”，是响应内容密度
写 @media (max-width: 768px) 然后把所有东西缩成一列，是入门陷阱。真实项目里，一个宽屏报表页在小屏上不是“缩小”，而是切换为可横向滚动的卡片流；一个图文混排的详情页，在中屏可能需要两栏，在大屏反而要收窄阅读宽度提升可读性。媒体查询的本质，是根据可用空间密度重新组织信息层级，不是简单“变小”。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
min-width为主，从移动开始渐进增强，避免在大屏 CSS 里用!important覆盖小屏规则 - 关键断点按内容定，不是按设备定：比如
48ch（字符宽度）比768px更可靠，适合文本密集型页面 - 用
container查询替代全局 media query：给特定模块加container-type: inline-size，让它自己响应内部宽度，不污染全局布局流
真正卡住人的，从来不是某个属性不会写，而是没想清楚这个样式到底是在描述结构、承载状态，还是响应上下文。写完一段 CSS，不妨问一句：如果明天产品经理说“这个模块要挪到侧边栏”，这段样式是跟着走，还是得重写？答案往往就在 class 名和选择器深度里。
