li:not(:last-child)是最直接、语义最清晰的选择器，能精准排除最后一个li的边框，不依赖索引且兼容混杂子元素；但遇空白节点、flex/grid布局或框架条件渲染时易失效。
li:not(:last-child) 是最直接、语义最清晰的选择器，能快速排除最后一个列表项的边框。它不依赖计数或索引，只看 DOM 中真实的兄弟顺序，增删 li 时自动生效。
为什么不用 li:last-child 单独控制？
单独写 li:last-child { border-bottom: none; } 看似等价，但实际是「先加线再清除」，而 li:not(:last-child) 是「只给该加的加」——后者更符合“意图优先”的样式逻辑。更重要的是，当父容器里混有其他类型子元素（比如 li 后面跟着一个 div 或注释节点），:last-child 会指向那个 div，导致所有 li 都被加上边框。此时 li:not(:last-child) 仍能正确工作，因为它只作用于 li 元素本身，再从中排除最后一个。
li:not(:last-child) 容易失效的三个真实场景
- 父容器内存在空白文本节点（换行、缩进空格）：浏览器会把它们当作子节点，导致真正的最后一个
li不是:last-child—— 解决办法是写成ul > li:not(:last-child)并确保 HTML 中li之间无换行/空格，或改用li:not(:last-of-type)（注意兼容性） - 使用了
display: flex或grid且启用了flex-wrap/grid-auto-flow：视觉顺序 ≠ DOM 顺序，:last-child依然按源码位置判定，不会随布局重排变化 - 在 React/Vue 等框架中条件渲染跳过某些
li（如v-if或key复用）：DOM 结构可能和预期不一致，此时 JS 层面的list.length - 1判定和 CSS 的:last-child行为不等价
border-bottom 还是 border-top？方向选错会影响对齐
绝大多数情况下优先用 border-bottom：
-
border-bottom更稳定：不受父容器overflow: hidden或transform影响 - 移动端折叠列表时，视觉上“最后一项”可能变成第一行，但 DOM 顺序未变，
:last-child仍准确 —— 此时若误用border-top，容易漏掉顶部第一条线 - 如果列表项高度不固定（比如含多行文字），
border-top更容易和上一项的文字基线对齐；但需额外处理第一个li的border-top: none
真正复杂的地方不在语法，而在你写的 HTML 是否和选择器“看到”的 DOM 一致——哪怕多一个换行符，:last-child 就可能指错对象。
立即学习“前端免费学习笔记（深入）”；
