应让a或button自身撑开热区，而非仅给li加padding；需设display:inline-block/block、padding≥12px、min-height:44px，并优先用button替代a实现交互功能。
li 本身不是可交互元素，直接点击它不会触发任何行为——除非你给它加了 onclick 或绑了事件，但那样既不语义化，也破坏键盘导航和屏幕阅读器支持。真正该扩大的，是它内部的 a 或 button；而最省心、最合规的做法，是让这些控件自己撑开热区。
为什么只给 li 加 padding 不行
很多开发者习惯给 li 设 padding，以为这样就能扩大点击范围。但问题在于：li 默认是块级容器，没有默认交互行为；哪怕你加了 cursor: pointer，点击空白处也不会跳转或提交。用户实际要操作的是里面的 a 或 button，热区必须落在它们身上。
-
li的padding只是视觉留白，不传递点击事件到子元素 - 若
a是inline元素，它的宽高仍只包裹文字，li的 padding 区域不可点 - 在移动端，未达 44×44px 的
a容易误触或无响应，iOS Safari 会降权处理
用 a 自身撑开热区（推荐）
把点击目标前移——让链接自己成为完整可点区域，而不是依赖父容器。关键就两步：改显示模式 + 加内边距。
- 设
display: inline-block或display: block，使padding和min-height生效 - 加
padding: 12px 16px（移动端建议 ≥12px 上下），比单纯调大font-size更可靠 - 配
min-height: 44px，确保小屏下物理尺寸达标；避免用height固定死，防文字换行错位 - 移除
margin（尤其是上下 margin），它不参与热区，还可能造成布局空隙不可点
nav ul li a {
display: inline-block;
padding: 12px 16px;
min-height: 44px;
text-decoration: none;
line-height: 1.2;
}
用 button 替代 a 的场景
当列表项要触发 JS 行为（如展开菜单、切换标签页），别用 a href="#" 再 preventDefault() —— 这破坏语义且对键盘用户不友好。直接用 button，它天生可聚焦、可空格/回车触发，热区也更容易控制。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
-
button默认是inline-block，padding直接生效 - 避免写
type="button"（虽安全，但冗余），无type属性时默认就是 button - 若需禁用选中文本，用
-webkit-user-select: none; -moz-user-select: none;，别用user-select: none，后者在部分 Android WebView 中会连带抑制 click - 注意：不要给
button设pointer-events: none或opacity: 0，否则热区彻底失效
Flex 布局下容易忽略的对齐偏移
当 nav ul 用 display: flex，而 li a 是 inline-block 时，常见问题是文字和图标垂直错位，导致点击区域“上移”或“下空”。这不是 bug，是 vertical-align 和基线对齐惹的祸。
- 给
a加align-items: center无效（它是 inline 元素），得用display: flex+align-items: center才能真正居中 - 更稳妥的写法：把
a设为display: flex，再用justify-content: center和align-items: center - 检查 computed styles 中
line-height是否过大，压缩了可点击高度；建议设为line-height: 1.2或1.3，而非固定像素值 - 真机测试时，打开「辅助功能 > 触控调节」，观察是否出现延迟响应或需双击才触发——这往往是
touch-action: none或热区尺寸不足的信号
最常被忽略的一点：热区是否有效，不能靠桌面浏览器模拟器判断。iOS Safari 对 label 和 a 的热区映射有独立逻辑，Android WebView 对 user-select 的处理也不一致。上线前务必在真机上用 Chrome DevTools 的「Rendering > Emulate touch events」关闭状态实测点击反馈。
