侧边栏必须用包裹列表，不可仅用套；提供语义与可访问性支持，明确表达并列导航入口，混用将导致语义缺失、无障碍支持差、SEO弱化。
侧边栏用 nav 包裹列表，不是随便套 div
直接用 div 套 ul 也能显示，但语义错误、无障碍支持差、SEO 友好度低。浏览器和读屏软件会把 nav 当作导航区域识别，ul 则明确表达“一组可并列访问的入口”。
常见错误是写成：<div class="sidebar"><ul>...</ul></div> —— 这等于放弃语义，后期维护或改用 JS 控制焦点时会多踩三四个坑。
-
nav是语义容器，必须包裹整个导航逻辑块（含标题、列表、可能的搜索框） - 列表项
li内必须用a标签，不能只放文字或靠 JS 绑定点击 - 如果侧边栏有主标题（如“栏目导航”），建议用
h2，不要用div+ CSS 模拟标题
ul 里嵌 a 的 href 和 target 要按需设，别全写 # 或 _blank
href 写成 # 看似省事，但会导致页面跳到顶部、破坏滚动位置、影响 history API 使用；全用 _blank 则打乱用户浏览上下文，尤其移动端容易丢失原页。
真实场景中：
立即学习“前端免费学习笔记（深入）”；
- 站内跳转：用相对路径，如
href="article.html"或带 hash 的锚点href="index.html#contact" - 外部链接：加
rel="noopener noreferrer"防安全漏洞，例如<a href="https://example.com" target="_blank" rel="noopener noreferrer">官网</a> - 纯 JS 触发动作（如展开子菜单）：用
href="javascript:void(0)"或href="#"+event.preventDefault()，但必须配aria-expanded等可访问属性
多级侧边栏用嵌套 ul，别用 ol 或 dl
二级菜单本质仍是导航选项集合，不是有序步骤（不用 ol），也不是术语解释（不用 dl）。正确做法是 li 里再包一层 ul，且外层 li 要有明确角色标识。
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
示例结构：
<nav aria-label="主菜单">
<ul>
<li><a href="home.html">首页</a></li>
<li>
<a href="#" aria-expanded="false" aria-haspopup="true">产品</a>
<ul>
<li><a href="pro-a.html">产品A</a></li>
<li><a href="pro-b.html">产品B</a></li>
</ul>
</li>
</ul>
</nav>
注意点：
- 子菜单
ul必须紧跟在触发它的li内部，不能脱离父li单独存在 - 用
aria-haspopup="true"和aria-expanded告诉辅助技术这是可展开项 - CSS 控制显隐时，优先用
display: none/block或visibility: hidden/visible，避免仅靠opacity: 0—— 后者仍占可访问焦点流
侧边栏宽度和定位别只靠 float 或内联 style
现在还用 float: left 布局侧边栏，会触发 BFC 问题、清除浮动麻烦、响应式难适配。内联 style="width: 200px;" 则无法复用、不利于主题切换。
推荐组合：
- 结构层用
aside或nav（根据是否属于全局导航判断） - 布局层用 CSS Grid 或 Flex：比如
display: grid; grid-template-columns: 240px 1fr; - 移动端收起时，用
transform: translateX(-100%)+transition，比left: -240px更性能友好 - 固定定位（
position: fixed）侧边栏要手动处理top和height，否则滚动时内容会被遮挡
真正难的不是写出能看的侧边栏，而是让它在键盘 Tab 流中顺序合理、在窄屏下不撑破布局、在 JS 失效时仍可点击跳转——这些细节一旦漏掉，修复成本远高于初始设计。
