HTML无法实现交互通知面板，需JS控制DOM与状态、CSS实现动效；结构须语义清晰、层级扁平、关键节点带明确属性；CSS动画应避免height: auto过渡，改用max-height或transform: scaleY()；JS需维护独立未读数变量、乐观更新、多端同步及焦点管理。
HTML 本身做不出可交互的通知中心面板——它只是结构，真正实现下拉、展开、标记已读、清空这些行为，必须靠 JavaScript 控制 DOM 和状态，CSS 负责动效与布局。面试时如果只写一堆 <div> 和 <code><ul></ul>，基本等于没答到点上。
通知面板的 HTML 结构怎么组织才利于 JS 控制
结构要语义清晰、层级扁平、关键节点带明确 class 或 data- 属性，避免靠嵌套深度定位元素。比如通知列表用 <ul class="notification-list"></ul>，每条通知用 <li data-id="123" data-read="false">，这样 JS 可以直接按属性筛选未读项或批量操作。
- 根容器加
role="region"和aria-labelledby，方便屏幕阅读器识别 - 下拉触发按钮必须是
<button></button>（不是<div>），并用 <code>aria-expanded同步开关状态 - 通知项里关键操作（如“标记为已读”）用
<button type="button"></button>，防止意外提交表单 - 避免在 HTML 里硬编码图标或徽标数字，统一由 JS 注入或 CSS 伪元素生成
- 用
transform方案更可靠：初始transform: scaleY(0)，展开时设为scaleY(1)，同时加transform-origin: top - 必须配
overflow: hidden，否则内容会溢出显示 - 过渡时间建议 ≤ 0.25s，太慢显得卡顿，太快用户感知不到状态变化
- 不要依赖
display: none/block切换——它无法过渡，且会破坏焦点管理 - 首次加载时，从 API 获取
unread_count，再渲染通知列表；不要先渲染再发请求查未读数 - 点击“标记全部为已读”时，先本地把所有
data-read改为"true"，UI 立即更新徽标，再异步调用markAllAsRead()接口 - 监听
visibilitychange事件，在页面切回前台时主动拉一次未读数，避免后台静默新增通知却没提示 - 徽标数字（如右上角小红点）必须用单独变量维护，不要每次靠
document.querySelectorAll('[data-read="false"]').length计算——DOM 查询开销大，且可能漏掉尚未插入 DOM 的新通知
用 CSS 实现平滑下拉动画的关键约束
CSS 过渡不能直接作用于 height: auto，所以常见错误是给 .notification-panel 直接加 transition: height 0.2s——结果动画不生效。正确做法是用 max-height 配合足够大的固定值（如 max-height: 500px），或改用 transform: scaleY() + overflow: hidden。
JavaScript 怎么处理通知的“未读数”同步逻辑
未读数不是简单统计 DOM 里有多少 data-read="false" 的 <li>，它必须和后端状态对齐，且要考虑用户多端登录、手动刷新、离线操作等场景。前端只负责缓存+乐观更新，最终以接口返回为准。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
最常被忽略的是焦点管理：下拉展开后，键盘用户按 Tab 应该能进入面板内操作，关闭时焦点要回到触发按钮；还有移动端点击空白处收起面板的逻辑，得监听 click 事件捕获阶段并判断 event.target 是否在面板外——这些细节不处理，功能就算“能用”，也过不了资深面试官那关。
