DOCTYPE声明错误会导致浏览器进入怪异模式，使box-sizing等布局行为退化为IE5.5风格；div+css失效常因标准流理解偏差，如浮动未清除致高度塌陷；语义化标签影响可访问性与SEO；table仅适用于真实表格数据。
DOCTYPE 声明直接影响浏览器渲染模式
没有 或声明错误（比如写成 <code>、漏掉空格、大小写混用），浏览器会进入怪异模式（Quirks Mode）。这时 <code>box-sizing、width 计算、margin 折叠等行为全部退化回 IE5.5 风格——不是“看起来有点不一样”，而是布局逻辑彻底错乱。
常见误操作包括：
- 在 VS Code 中敲
!生成模板后手动删掉（以为只是注释） - 复制他人代码时只复制了
开始的部分，漏掉首行 - 用旧工具导出 HTML，自动生成
这类过时声明
验证方式：打开开发者工具 → 切换到 Console 标签页 → 输入 document.compatMode。返回 "CSS1Compat" 才是标准模式；"BackCompat" 就是怪异模式，必须修正 DOCTYPE。
div+css 布局失效的典型根源在标准流认知偏差
很多人写 <div class="header"></div>
<div class="main"></div> 却发现两个 <div> 堆叠错位、高度塌陷、浮动不生效，问题往往不在 CSS，而在对标准流的理解断层。<p>关键事实：</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill9972" title="Wechat Article Html"><img
src="https://img.php.cn/upload/skill/001/246/273/6adaf20e695c2374.jpg" alt="Wechat Article Html" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill9972" title="Wechat Article Html" class="overflowclass">Wechat Article Html</a>
<p class="overflowclass">将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。</p>
</div>
<a rel="nofollow" href="/xiazai/skill9972" title="Wechat Article Html" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
<ul><li><code><div> 默认是块级元素，天然独占一行、宽度撑满父容器，但它的高度由内容撑开——如果内部只有浮动子元素，它就会“看不见”那些子元素，高度变成 0
<li>所谓“脱离标准流”，不是加个 <code>position: absolute 就万事大吉；float 也会让元素脱离标准流，但父容器仍需清除浮动（clear: both 或 BFC 触发）
display: inline-block 看似折中，但元素间换行符会被渲染为空格，导致意外间隙——这不是 bug，是标准流对空白符的正常处理简单验证：给父 <div> 加 <code>border: 1px solid red，再放几个子 <div>，立刻看清谁真正占了空间、谁“消失”了。<h3>语义化标签不是装饰，它改写 CSS 作用域与可访问性边界</h3>
<p>把 <code><nav></nav> 换成 <div class="nav">，视觉上可能毫无差别，但实际影响三处硬约束：<ul>
<li>CSS 选择器权重不变，但屏幕阅读器无法识别导航区域，WCAG 合规性直接失败</li>
<li>搜索引擎对 <code><article></article> 内容的权重显著高于普通 <div>，尤其在长文或博客场景
<li>当用 <code>display: contents 或 Grid/Flex 布局时，<section></section> 和 <div> 的 DOM 行为一致，但前者在 devtools 的 Accessibility 面板里会显示明确的“Section”角色，后者是“Generic”
<p>真实陷阱：有人为“保持语义”强行套用 <code><aside></aside>，结果里面塞了主菜单——这违反 W3C 定义：<aside></aside> 应该是“与主内容相关但可独立存在”的内容（如侧边广告、作者简介），不是“放在右边的盒子”。
table 布局在现代页面中唯一合理场景是表格数据
用 <table> 实现导航栏、卡片栅格、表单排版，短期内能跑通，但代价是刚性耦合：<ul><li>响应式断点几乎不可控：媒体查询无法单独干预 <code><td> 的换行逻辑，只能整表隐藏或缩放
<li>SEO 友好度归零：搜索引擎把整个 <code><table> 当作一个数据单元解析，内部文字权重被严重稀释
<li>维护成本指数上升：增删一列要同步改 <code><thead>、<code><tbody>、所有 <code><tr>，而 Flex/Grid 只需调一个容器属性
<p>例外情况：后台系统的日志列表、财务报表、带固定行列头的监控指标看板——这些本质就是二维结构化数据，<code><table> 不仅合理，且 <code><th scope="col"> + <code><caption></caption> 能提供原生可访问性支持。
真正容易被忽略的是：哪怕你只用了一次 <table> 做布局，整页的渲染流水线都会被迫按表格算法重排——它比 div+css 多一次“计算列宽→分配剩余空间→重绘单元格”的完整周期，尤其在低端设备上延迟明显。</table>
