ul中直接写文字或div会“消失”是因为HTML规范强制要求ul的直接子元素只能是li，非法内容被浏览器容错修复但行为不可控；子ul必须嵌套在li内部而非与li并列；list-style-type失效源于li的display值被修改；导航菜单需用nav包裹且每个li内必须包含a标签。
ul里直接写文字或div为什么会“消失”
浏览器不会报错，但内容实际被移出
- 结构——比如
- ，行为不可控。
根本原因是HTML规范强制要求
ul的直接子元素只能是li。任何其他内容（纯文本、<div>、<p>等）都属于非法嵌套，浏览器会“容错修复”，但修复方式不统一、不保证可访问性。- 所有列表项内容必须显式用
li包裹，哪怕只有一行文字 - 若需在列表项中加段落、链接或图标，把它们放进
li内部，而不是绕过li直接塞进ul - 依赖浏览器自动补全会破坏屏幕阅读器播报逻辑，键盘Tab焦点也可能跳过该内容
嵌套二级菜单时ul放错位置的典型错误
常见误写是把子
ul和父级并列，例如：<ul><li>首页</li><ul><li>关于我们</li></ul></ul>。这个子ul不在任何li内部，浏览器会把它当作一个全新、无父级的列表处理。结果就是“关于我们”脱离导航上下文：CSS定位失效、
:hover选择器断链、键盘焦点无法进入子菜单。立即学习“前端免费学习笔记（深入）”；
- 子
ul必须完整写在某个li的起始与闭合标签之间，例如：<li>服务<ul><li>技术支持</li></ul></li> - 嵌套层级本身无硬性限制，但超过3层后，屏幕阅读器可能难以准确识别父子关系，建议用
nav明确语义边界 - 不要用
div或span包裹li再放子ul——这会让li:hover > ul这类关键选择器失效
list-style-type不生效的真正原因
不是CSS写错了，而是
li的display值被改掉了。list-style-type只对display: list-item生效，而这是li的默认值。一旦设成display: flex、display: inline-block或display: grid，符号就立刻消失。- 横向排列列表时，优先改
ul为display: flex，保持li的display: list-item不变 - 若必须改
li的display，记得手动补回list-style-position: inside和vertical-align: top对齐符号 -
list-style: none比list-style-type: none更彻底——它同时清除符号、位置和自定义图片 -
type属性（如<ul type="square">）在HTML5中已废弃，现代浏览器基本忽略，验证器会报警告
用ul+li做导航菜单最常漏掉的关键点
很多人只写
<ul><li>首页</li></ul>，却忘了导航的本质是“可跳转的操作项”。li本身没有交互能力，也不具备语义上的“链接”含义。- 每个
li内必须包含可聚焦、可点击的a标签，否则键盘用户无法访问，屏幕阅读器也不会读作“导航链接” - 最外层必须用
nav包裹，不能省略——nav是唯一被所有主流读屏软件一致识别为“导航区域”的容器 - 缩进必须用
padding-left逐级累加，禁用margin-left或text-indent：前者破坏Tab顺序，后者只缩第一行文字，图标和箭头位置失控 - 悬停展开用
li:hover > ul，但必须同步支持li:focus-within > ul，否则键盘用户无法触发子菜单
结构错一点，视觉可能看不出来，但对键盘操作、语音控制、SEO的影响是真实且隐蔽的。别让“看起来一样”成为跳过语义的理由。
- 所有列表项内容必须显式用
<ul>苹果</ul>中的“苹果”可能渲染在- 标签外部，或被自动包裹进一个隐式
