用 padding-left 更稳妥。它使整个评论块（含头像、边框、背景）统一缩进，避免 margin-left 导致的头像错位、边框断裂和 hover 区域不连续等问题。
评论嵌套缩进用 margin-left 还是 padding-left？
用 padding-left 更稳妥。它让整个评论块（含头像、边框、背景）一起缩进，视觉统一；而 margin-left 只推内容区，容易导致头像错位、边框断裂或 hover 区域不连续。
常见错误是给每层子评论加固定 margin-left: 20px，结果三级评论缩进 60px，四级 80px——层级一多就挤出容器，尤其在移动端。
- 推荐用 CSS 自定义属性控制缩进基准：
--indent-step: 16px，再通过padding-left: calc(var(--indent-step) * var(--depth))动态计算（需配合 HTML 的data-depth属性） - 若用 BEM，可写成
.comment--level-2、.comment--level-3等类名，避免深度依赖 DOM 层级 - 注意：不要用
text-indent，它只缩进第一行，对多行评论完全无效
如何避免子评论的 border-left 在缩进后断开？
border-left 断开的本质是父容器没包住子评论的缩进区域——它的 border-left 默认从父容器左内边距起始，而子评论的 padding-left 把内容往右推了，视觉上就像“断了”。
解决方法不是加粗边框，而是让边框也参与缩进逻辑：
立即学习“前端免费学习笔记（深入）”；
- 把
border-left移到子评论自身，并配合padding-left同步缩进，例如：.comment__reply { border-left: 2px solid #e0e0e0; padding-left: 24px; } - 或者用伪元素模拟边框：
.comment__reply::before { content: ""; position: absolute; left: 0; top: 0; bottom: 0; width: 2px; background: #e0e0e0; }，再用transform: translateX(var(--indent-step))控制位置 - 切忌在父容器上设
overflow: hidden，否则会裁掉子评论的缩进部分
用 CSS :has() 实现“有子评论才显示展开按钮”靠谱吗？
目前（2024 年中）不建议线上项目依赖 :has() 做核心交互判断。Chrome 和 Safari 已支持，但 Firefox 仅从 v125 开始支持，且旧版 iOS Safari 完全不识别——用户点不动“展开”按钮，评论就永远藏在下面。
更实际的做法是服务端或构建时注入一个 class：
- 后端渲染时加
class="comment--has-replies"，前端只负责样式和 click 事件 - 如果纯前端渲染，初始化时遍历
.comment，检查是否有.comment__replies > .comment子节点，再补 class - 不要用
:has(.comment__replies)控制按钮显隐，因为首次加载时 JS 尚未运行，CSS 已生效，按钮可能误隐藏
移动端缩进太深导致文字换行异常怎么办？
缩进值固定（比如每层 +20px）在小屏上很快吃掉可用宽度，造成短文本也强制换行，甚至出现滚动条。这不是 bug，是线性缩进模型在响应式场景下的天然缺陷。
- 用媒体查询阶梯降级缩进值：
@media (max-width: 480px) { .comment--level-2 { padding-left: 12px; } .comment--level-3 { padding-left: 16px; } } - 更彻底的方案：超过两级嵌套后改用「折叠式」展示，即只显示第一层回复，其余收进
<details><summary>查看 3 条回复</summary></details>中 - 别忘了测试
word-break: break-word和hyphens: auto对长英文/URL 的影响，否则缩进+窄屏会让链接撑破容器
嵌套缩进看着简单，真正卡住人的往往是缩进与边框、响应式、可访问性三者的交叠——比如屏幕阅读器读到 aria-expanded 时，对应 DOM 结构却因缩进 class 错位而无法同步状态。这种细节，调试起来比写代码还花时间。
