一串文件名怎样撑宽了卡片

一个没有空格的文件名，把原本正常的双栏卡片撑宽了。沿着网格逐层检查，我发现文字列和外层内容区都可能被默认的最小尺寸卡住。处理标题时可以给长字符留出断行机会，代码则需要保留行宽，在自己的区域里滚动。最后再用长路径和连续中文各试一次。

找到第一个变宽的元素

问题出现在双栏卡片里：左侧文字，右侧缩略图。普通标题完全正常，换成一串没有空格的文件名后，卡片把页面撑宽了。第一反应是调小字号，但即使缩到很小，横向滚动仍然存在。

我在开发者工具里逐层选中元素，才看到文字所在的网格项没有按预期缩小。它的默认最小尺寸与内容有关；那串连续字符，恰好提供了很大的最小宽度。

把收缩权限交给容器

在这个布局中，文字列本来就应该允许缩小。我给它设置明确的最小宽度，再对连续字符提供断行机会：

.card {
  display: grid;
  grid-template-columns: minmax(0, 1fr) 10rem;
  gap: 1.5rem;
}
.card__content {
  min-width: 0;
}
.card__title {
  overflow-wrap: anywhere;
}
pre {
  max-width: 100%;
  overflow-x: auto;
}

标题可以换行，代码则保留格式，在自己的区域内横向滚动。把所有内容都强行折行，虽然能消除溢出，却会让代码难以阅读。

用故意难看的内容检查

修正以后，我没有只看原先那篇文章，而是放进更难处理的内容：长英文单词、很深的文件路径、没有空格的编号，以及连续中文标题。分别在窄屏和桌面上检查，确认图片没有被挤成一条，正文也没有出现整页横向滚动。

我还用键盘移动焦点，检查被滚动容器包住的链接是否仍然可见。一个区域能滚动，并不代表里面的内容就一定容易到达。

最后留下的改动很小。花时间的是找到谁在决定尺寸，以及分清哪些内容应该换行、哪些应该局部滚动。以后再遇到溢出，我会先检查约束，不急着改变字体。

再检查一层网格

第一次加上断行规则后，我以为问题已经解决。直到把卡片放回完整页面，外侧又出现一条细小的滚动条。这次撑开页面的是另一个网格项：卡片本身放在内容列里，内容列仍然保留着默认的最小尺寸。

这提醒我，尺寸约束会沿着祖先链传递。一个孩子愿意缩小，不代表包住它的每一层都愿意缩小。我把调试顺序改成从最外层开始，每次只检查一个边界，直到找到第一个超出视口的盒子。

不要把隐藏当成修复

给页面加上 overflow-x: hidden，可以让滚动条消失，但被裁掉的内容并没有回来。如果右侧刚好有一个按钮，它可能从此无法被看见；键盘焦点仍然可能移动到那个位置，读者却不知道发生了什么。

我只在装饰元素确实应该被裁切时使用隐藏。对于正文、表格、操作按钮，先弄清楚它们需要的空间，再决定换行、改变布局或提供局部滚动。

表格与代码需要不同的判断

表格里的每一列都有比较关系，过度压缩会让读者忘记自己正在比较什么。列数很少时，我会先缩短单元格文字；列数很多时，宁愿让表格在局部滚动，也不把每个字拆成一行。

代码则有另一种连续性。缩进、符号与一行表达式的关系值得保留。下面这行故意较长，用来检查代码区域是否独立滚动，而不是迫使整个页面横向移动：

1	const imageCandidates = records.filter(record => record.kind === 'image' && record.width >= 960 && record.height >= 600).map(record => ({ source: record.path, ratio: record.width / record.height }));

这不是为了推荐把表达式写成一长行。实际项目里，我会按阅读逻辑拆开它；演示时留下长行，是为了确认容器在不理想的输入下仍然能工作。

一次可以重复的排查顺序

我把这次经验整理成了五步，贴在工作笔记的末尾：

找到第一个超出视口的元素，不只看最显眼的那个。
沿父级检查网格、弹性布局与最小尺寸。
判断内容应该换行、重排，还是保留局部滚动。
用更长的标题、路径和空值重新检查。
回到真实页面，确认焦点、图片与正文都没有受影响。

这些步骤不依赖某个具体框架。真正有用的是把“页面宽了”拆成几个可以观察的事实：谁变宽、受谁约束、内容是否还在，以及读者能不能到达它。

我也保留了一份修复前的最小片段。下次再遇到相似问题，与其凭记忆复制规则，不如先在小片段中确认原因，再把必要的改动带回完整页面。这样多花几分钟，通常比事后清理一串相互覆盖的样式更轻松。