ul中直接写文字或div会“消失”是因为html规范强制要求ul的直接子元素只能是li，非法内容被浏览器容错修复但行为不可控；子ul必须嵌套在li内部而非与li并列；list-style-type失效源于li的display值被修改；导航菜单需用nav包裹且每个li内必须包含a标签。

ul里直接写文字或div为什么会“消失”

浏览器不会报错，但内容实际被移出

结构——比如<ul>苹果</ul>中的“苹果”可能渲染在
标签外部，或被自动包裹进一个隐式
• ，行为不可控。

  根本原因是HTML规范强制要求ul的直接子元素只能是li。任何其他内容（纯文本、<div>、<code><p></p>等）都属于非法嵌套，浏览器会“容错修复”，但修复方式不统一、不保证可访问性。

  • 所有列表项内容必须显式用li包裹，哪怕只有一行文字
  • 若需在列表项中加段落、链接或图标，把它们放进li内部，而不是绕过li直接塞进ul
  • 依赖浏览器自动补全会破坏屏幕阅读器播报逻辑，键盘Tab焦点也可能跳过该内容

  嵌套二级菜单时ul放错位置的典型错误

  常见误写是把子ul和父级并列，例如：<ul> <li>首页</li> <ul><li>关于我们</li></ul> </ul>。这个子ul不在任何li内部，浏览器会把它当作一个全新、无父级的列表处理。

  结果就是“关于我们”脱离导航上下文：CSS定位失效、:hover选择器断链、键盘焦点无法进入子菜单。

  

  html-deploy

  使用 htmlcode.fun 将 HTML 内容或文件部署到网页，适用于用户要求“部署到网页”“托管此 HTML”“生成此前端...的实时链接”等场景。

  下载
  • 子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"></ul>）在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的影响是真实且隐蔽的。别让“看起来一样”成为跳过语义的理由。