现代双栏布局优先用 Flex：Flex 主轴天然适配左右分布，兼容性好、调试直观；Grid 在简单场景易因隐式轨道导致换行，响应式切换也更复杂。
左右双栏布局该用 Flex 还是 Grid？
现代项目直接选 display: flex，除非你要做语义化段落级对齐（比如 AI 翻译对照），才考虑 display: grid。Flex 更稳、兼容性更好、调试直观；Grid 在双栏这种简单场景里反而容易因隐式轨道或 minmax() 行为导致意外换行。
关键区别在于：Flex 把容器当一维主轴处理，左右两栏天然就是“主轴两端”；Grid 默认二维，哪怕只写两列，也得额外防止单元格内容撑破、自动换行或基线错位。
-
flex下，右侧栏用flex: 1即可自适应，不用算像素或百分比 -
grid下，grid-template-columns: 200px 1fr看似简洁，但若左侧有滚动内容，右侧1fr可能被压缩——尤其在 Safari 旧版中 - 移动端切单列时，
@media (max-width: 768px)里改flex-direction: column比改grid-template-rows更可靠
左侧菜单固定高度 + 独立滚动怎么写不塌？
常见现象是左侧菜单只滚到中间就卡住，最后一项看不见。根本不是 JS 事件没绑好，而是 CSS 高度链断了：父容器没设高度来源，overflow-y: auto 就没作用范围。
正确做法是切断文档流依赖，用视口单位锚定起点：
- 外层容器（如
<main></main>）设height: calc(100vh - 64px)（减去 header 高度） - 左侧栏设
height: 100%+overflow-y: auto，不要用min-height - 避免在左侧栏上设
position: absolute或float，这会让它脱离 flex 主轴高度继承 - 如果用了 iframe 做右侧内容区，iframe 自身也要设
height: 100%，否则它会按内容撑高，拖垮整体布局
为什么 display: table 双栏现在基本不能碰？
除非你正在维护 2012 年上线、至今没升级过 IE10 的银行内网系统，否则别碰 display: table。它不是“老但能用”，而是结构性不可维护。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
典型翻车点：
- 右侧内容突然掉到下一行：IE 下
table-cell不写像素宽度（如width: 200px）就按内容收缩，width: 100%完全无效 - 背景色左右不对齐：两个
table-cell高度各自由内容决定，不会等高；想视觉一致只能 JS 计算或硬写min-height - 移动端完全失能：媒体查询无法让
table-cell切成块级堆叠，必须靠 JS 动态切 class，等于把响应式逻辑写死在业务层 - 屏幕阅读器会把整个布局读成“一个表格”，含 2 行 2 列——即便你只是想放导航和内容
iframe 做右侧内容区要注意什么？
用 <iframe></iframe> 实现右侧动态加载很常见，但容易忽略三件事：尺寸同步、跨域通信、默认样式污染。
实际部署中最常漏的配置：
-
iframe必须设width: 100%和height: 100%，且父容器不能是display: inline类型 - 如果加载的是同域 HTML，可通过
iframe.contentDocument注入样式重置（比如清除body margin） - 加载跨域页面时，
iframe内容无法用 JS 获取，但可用postMessage做有限通信——比如通知左侧菜单高亮当前项 - 别依赖
iframe onload做初始化，某些 Chromium 版本下它会在页面 DOM 尚未 ready 时触发
真正难的从来不是“怎么让两栏并排”，而是当左侧要滚动、右侧要 iframe 加载、顶部有 sticky header、底部有 fixed toolbar 时，如何让所有高度计算不互相干扰。这时候再漂亮的 CSS 技巧都不如老老实实从 html, body { height: 100% } 开始推一遍继承链。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
