表格布局登录表单属语义错误的反模式，因其破坏可访问性、键盘导航与响应式；若必须使用，须用th[scope="row"]配label[for]、显式id绑定、补救CSS及正确form属性。
表格布局做登录表单在语义上是错误的，但如果你必须用（比如 legacy 系统、老 IE 兼容需求或 CMS 模板限制），核心不是“能不能做”，而是“怎么避免被现代浏览器和辅助工具拒之门外”。
为什么 <table> 布局登录表单现在属于反模式
HTML 表格标签（<table>、<tr>、<td>）本意是展示二维数据，不是控制 UI 排版。用它布局表单会带来三类硬伤：
- 语义断裂：
<table>告诉屏幕阅读器“这里有一张数据表”，但实际是登录控件——读屏器会逐行读出“空单元格、空单元格”，用户完全无法理解上下文 - 键盘导航失效：多数旧式表格布局未设
tabindex或正确scope，Tab 键跳过输入框或顺序错乱 - 响应式崩坏：
width="500"这类内联属性在移动端直接溢出，且无法用 CSS@media可靠覆盖
<table> 布局中 label 和 input 必须手动对齐且可聚焦
不能依赖视觉居中，而要确保每个字段都具备可操作性。常见写法错误是把 <label> 和 <input> 都塞进同一个 <td> 里，导致点击文字不触发焦点。
- 正确结构：每行一个
<tr>，<th>放 label（加scope="row"），<td>放 input + 显式id -
<label for="xxx">必须存在，且for值与<input id="xxx">严格一致——哪怕用了表格，这层绑定也不能省 - 避免
<label>用户名<input></label>嵌套，部分旧 WebView 不识别这种写法
示例最小可行片段：
立即学习“前端免费学习笔记（深入）”；
<form action="/login" method="post">
<table>
<tr>
<th scope="row"><label for="username">用户名</label></th>
<td><input type="text" id="username" name="username" required></td>
</tr>
<tr>
<th scope="row"><label for="password">密码</label></th>
<td><input type="password" id="password" name="password" required></td>
</tr>
<tr>
<td colspan="2"><input type="submit" value="登录"></td>
</tr>
</table>
</form>必须加的 CSS 补救措施（否则移动端直接不可用）
仅靠 HTML 表格属性（如 width="400"）在高 DPI 屏或窄屏下必然失败。以下三行 CSS 是底线：
-
* { box-sizing: border-box; }：防止padding+border把<td>帐撑爆 -
table { width: 100%; max-width: 480px; margin: 0 auto; }：约束宽度，避免横滚 -
input, button { width: 100%; font-size: 16px; }：确保软键盘弹起时输入框可点击，且文字大小不低于可读下限
别信“表格天然居中”——<table align="center"> 在 Flexbox / Grid 主导的页面里经常被重置，显式 margin: 0 auto 更可靠。
method 和 action 错误会导致整个表单静默失效
用表格包裹，不代表能绕过表单基本协议。90% 的“点不动”问题，根源不在表格，而在 <form> 标签本身。
-
method必须小写"post"；写成"POST"在部分嵌入式浏览器（如某些机顶盒 Webkit）中会被忽略 -
action不能为空字符串""或缺失；若后端未就绪，填action="/login"比action="#"更好——前者至少发个 404 请求，你能从 DevTools Network 面板看到请求发出，后者连请求都没有 - 所有
<input>必须有name，且值要和后端约定一致；name="user"和name="username"对后端是两个不同字段
最后提醒一句：表格布局的登录表单，在 Chrome DevTools 的 Lighthouse 检测中，“可访问性”得分通常低于 40。如果项目允许重构，优先用语义化 <div> + CSS Grid/Flex，表格只留给真正需要展示表格数据的地方。
