社区页面不是靠“堆砌模块”做出来的，而是靠内容流结构、交互锚点、响应式断点三层配合；错误使用table或float会导致加载卡顿、无障碍失效、移动端滑动断裂，因table强制整表渲染且语义不符流式内容，而feed单列垂直流应优先用flex而非grid，辅以预留占位高度、min-width:0防溢出等细节保障顺滑与可访问。

使用华数设计生成高保真HTML原型、演示文稿、动画和设计评审

使用经过文档化的设计技能，从真实的品牌或项目背景中生成HTML原生原型、幻灯片、动态演示、可视化图表和评审流程。

下载

直接说结论：社区页面不是靠“堆砌模块”做出来的，而是靠**内容流结构 + 交互锚点 + 响应式断点**三层配合。用错布局方式（比如把整个 feed 区套 或滥用

+ float）会导致加载卡顿、无障碍支持失效、移动端滑动断裂。

为什么不能用 table 做社区主布局

浏览器会强制等待整张表渲染完才开始绘制，社区页通常含大量异步加载的动态卡片（如帖子、评论、点赞状态），<table> 会让首屏时间明显变长；更重要的是，表格语义是「行列对齐的数据关系」，而社区 feed 是「时间序+优先级+可交互的流式内容」，屏幕阅读器会把每条帖子读成“第1行第1列”，完全丢失上下文。 <ul> <li>即使加了 <code>role="list" 也难修复语义断裂

display: table-cell 在 flex/grid 主流方案下已无必要

某些 CMS 导出 HTML 仍带 table 布局，需手动替换为 <section></section> + <article></article>

feed 流该用 display: flex 还是 display: grid

选 display: flex，但仅限于**单列垂直流**（绝大多数社区首页/个人主页）。Grid 在这里属于杀鸡用牛刀：你不需要控制某条帖子横跨三列，也不需要定义“第2行第3列必须是广告位”。Flex 的 flex-direction: column + gap 足够干净。

• 父容器设 display: flex; flex-direction: column; gap: 16px;，子 <article></article> 自动等距排列
• 避免给子元素设 margin-bottom —— 容易和 gap 叠加导致间距翻倍
• 若需局部双列（如“热门标签”横向滚动区），单独对该区块用 display: flex; flex-wrap: nowrap; overflow-x: auto;

动态加载更多（infinite scroll）时 layout shift 怎么压住

关键不是隐藏 loading，而是**预留占位高度**。浏览器在插入新卡片瞬间重排，若没预估高度，会导致按钮上跳、输入框失焦、甚至触发 iOS Safari 的键盘收起。

• 服务端返回每条卡片的预估高度（例如统一按 180px，含头像、标题、两行摘要、操作栏）
• 前端用 height: 180px; + overflow: hidden; 给 loading 卡片占位
• 真实卡片插入后，用 transition: height 0.2s ease-out; 平滑展开（需配合 max-height 或 JS 动态写 height）
• 绝对别用 visibility: hidden 占位——它不占空间，照样 layout shift

侧边栏固定 + 主内容滚动分离怎么写不踩坑

用 display: flex 父容器 + min-height: 100vh，但必须关掉子元素的默认最小尺寸限制。否则在窄屏下，侧边栏文字撑宽导致横向滚动，或主内容被压缩到看不见。

立即学习“前端免费学习笔记（深入）”；

• 父容器：display: flex; min-height: 100vh;
• 侧边栏：flex: 0 0 260px; min-width: 0;（min-width: 0 允许文本折行，防溢出）
• 主内容区：flex: 1; overflow-y: auto; min-width: 0;（同样要 min-width: 0）
• 别用 position: sticky 做侧边栏固定——iOS Safari 对 sticky 的 top 计算不稳定，容易随滚动突然消失

社区页面最难的从来不是“怎么让三栏对齐”，而是**当第17条帖子带了个 4K 图片 + 3 层嵌套评论 + 一个 Web Component 标签云时，整个流还能保持滚动顺滑、焦点可访问、缩放不崩坏**。这些细节藏在 flex 的 min-width: 0、gap 的单位选择、以及每张卡片是否包裹了 <article></article> 语义标签里。