span语法本身正确但上下文脆弱，必须显式指定起点（如2/span 2）、避免硬编码线号、统一box-sizing、慎用grid-template-areas，并为IE11等旧环境降级为具体线号。
span 不指定起点，浏览器就自己猜
写 grid-column: span 2 看似简洁，实际等于 grid-column: auto / span 2 —— 起点由 grid-auto-flow、已放置元素顺序、隐式网格规则共同决定。没有上下文时，这个“auto”可能落在第 1 条线，也可能跳到第 5 条线，尤其当前面有空缺轨道或 order 打乱了自然流，结果完全不可控。
- 安全写法必须显式锁定起点：例如
grid-column: 2 / span 2（从第 2 条列线开始，跨 2 列） -
grid-row: span 3在只有 2 行显式定义的容器里，会触发隐式第 3 行，高度为auto，常导致高度突兀膨胀 - 负值线号可用（如
-2），但span -2是无效语法，整条规则会被浏览器静默丢弃
响应式切换时，线号“失效”了
桌面端设了 grid-template-columns: repeat(12, 1fr)，写 grid-column: 3 / span 4 占中间 4 列；切到移动端媒体查询改成 repeat(4, 1fr) 后，第 3 条线虽还存在，但 span 4 会试图延伸到第 7 条线——而此时只有 5 条线（4 列 → 5 条线），元素直接掉进隐式网格区域，视觉上“消失”或错位到右下角。
- 更稳的写法是用负向定位：
grid-column: 1 / -1（占满所有列），或grid-column: -4 / -1（倒数 4 列起占满） - 避免硬编码数字线号，改用
grid-area配合grid-template-areas，但要注意 Safari ≤10.1 和打印场景会静默丢弃该规则 - 调试时打开 Chrome/Firefox 的“显示网格线”，看到的数字就是真实线号——别猜，直接看
span 和 gap / box-sizing 叠加出意外空间
给 grid item 加 padding: 16px 后布局错位，表面是 span 问题，实则是空间计算被打破：grid-template-columns: 1fr 1fr 分配的是“扣除 gap 后的剩余宽度”，若再没设 box-sizing: border-box，item 实际宽 = 1fr + 32px，直接撑爆容器。
- 必须写全：
* { box-sizing: border-box; }+*::before, *::after { box-sizing: border-box; }，否则伪元素仍按content-box计算 -
gap是刚性占位，不是视觉留白：它从容器总宽里直接扣除，再分给轨道。子项别写width: 100%，它会无视gap强占整列 - 含文字的子项务必加
min-width: 0和overflow: hidden，防长 URL 或连续英文字符撑开轨道
IE11 和旧 WebView 中 span 根本不工作
span 本身语法没问题，但 IE11 完全不支持 grid-column: span N，整条声明被忽略；Android 4.4 WebView 连基础 grid-column-gap 都不认，更别说 span。
立即学习“前端免费学习笔记（深入）”；
- 降级方案：用具体线号代替，如
grid-column: 1 / 3（等价于span 2），兼容性更好 - 对 IE11，必须放弃
fr和span，改用像素或百分比 +display: inline-block模拟网格 - 打印预览中
grid-template-areas常被丢弃，此时span写法也失效，统一用线号定位更可靠
真正让 span 错乱的，从来不是语法本身，而是它依赖的上下文太脆弱：起点不确定、响应式线号漂移、空间计算被其他属性干扰、旧环境直接不识别。最省事的防御方式，就是永远显式写起点，永远验证隐式轨道是否真按你预期生成。
