用 > 生成父子嵌套时，> 只作用于紧邻右侧表达式，不跨括号或空格；括号是结构锚点，+ 表示同级追加，且 > 优先级高于 +，漏括号如 article>header+section 会误生成独立 section。
用 > 生成父子嵌套结构时，括号和空格会影响最终层级
Emmet 的 > 表示“子元素”，但它只作用于紧邻的右侧表达式，不会自动跨括号或空格延伸。比如 div>ul>li*3 会生成一个 div，里面一个 ul，再里面三个 li；但写成 div > ul > li*3（带空格）在多数编辑器里仍能识别，不过某些旧版插件可能失败。
常见错误是误以为 div>p>span 能直接生成三层嵌套，结果发现 span 没被包进 p —— 实际上它确实会，只要没混入意外符号。真正容易踩坑的是混合使用 () 和 >：例如 section>(header+main)+footer 中，> 只作用于括号整体，即 section 的子元素是整个 (header+main) 块和 footer，不是 header 或 main 单独作为 section 的子元素。
-
div>ul>li*2→ 正确嵌套：每个li都是ul的直接子项 -
div>(p>span)+h2→div下有两个子元素：p（内含span）和h2 - 避免写
div > (p > span) + h2，空格不必要，且部分 VS Code 版本对括号内空格解析不稳定
用 + 写兄弟元素时，顺序严格从左到右，不能反向推导
+ 是“同级追加”，它不关心左侧是否已有父容器，只把右边的元素作为与左边**最后一个节点同级**的新兄弟。这意味着你不能靠 + 回溯修改前面已生成的结构，它的作用域就是当前展开链的末尾位置。
典型误用是想写 header+main+footer 后再补个 nav 在 header 里，结果敲 header+main+footer+nav，发现 nav 跑到了 footer 同级——因为 + 始终接在前一个表达式的最右端，而不是“最近的未闭合标签”。
立即学习“前端免费学习笔记（深入）”；
-
header+main+footer→ 三个并列块，无嵌套 -
header>nav+div→header下两个子元素：nav和div - 想让
nav成为header子元素、同时main和footer并列？必须写成(header>nav)+main+footer
混合 > 和 + 时，运算优先级固定：> 高于 +
Emmet 解析时，> 总是先结合，再处理 +。这决定了括号往往不是可选项，而是结构控制的必要手段。不加括号时，a>b+c 等价于 (a>b)+c，而不是 a>(b+c) —— 这点和算术运算符习惯相反，容易下意识写错。
比如要生成「一个 article，里面包含 header 和 section 两个兄弟子元素」，正确写法是 article>(header+section)。如果漏掉括号写成 article>header+section，实际得到的是 article>header 加上一个独立的 section（同级），而非都作为 article 的子元素。
-
div>p+span→div下有p和span两个子元素 -
div>(p+span)→ 效果相同，但显式括号更安全、意图更清晰 -
div>p>span+em→p下有span和em两个子元素（>先绑定p>span，再+追加em）
VS Code 或 WebStorm 中触发失败？先检查缩写语法和触发键
Emmet 缩写不生效，90% 是因为没在 HTML 文件中、或没按对快捷键。VS Code 默认是 Tab，WebStorm 是 Ctrl+Enter（Windows/Linux）或 Cmd+Enter（macOS），且光标必须落在缩写末尾、不能有后续字符。
另一个隐蔽问题是语言模式：即使文件后缀是 .html，如果右下角状态栏显示的是 Plain Text 而非 HTML，Emmet 就不会激活。点击状态栏语言标签手动切回 HTML 即可。
- 确保文件关联为
HTML（不是HTML (Rails)或Vue等变体，除非插件明确支持） - 缩写中不要混入中文标点、全角空格或不可见 Unicode 字符
- 遇到
div>ul>li*5只展开前两层？可能是 Emmet 设置里禁用了abbreviation或启用了兼容模式，查emmet.includeLanguages和emmet.syntaxProfiles
> 和 + 的组合顺序一旦写错，生成的 DOM 树就偏离预期，而且这种错误在预览时很难一眼看出。 
