企业官网建设流程全解析

1. 为什么 UUID 总是把页面布局搞得一团糟

先说一个我自己的真实经历。之前做电商后台的订单系统，订单号用的就是 UUID。当时前端同事把订单列表做出来后，测试那边提了个 bug：订单号在表格里带着一串连字符弯弯绕绕地折行，一会儿在数字中间断开，一会儿从连字符后面断开，整个表格的行高和列宽都变得奇奇怪怪。当时第一反应是“不就是个换行吗，加个 word-break 不就行了”，结果真上手改了才发现，这里面的门道比想象中多得多。

UUID 的完整格式是 8-4-4-4-12 的 36 位字符串，例如9b1deb4d-3a7d-4bad-9bdd-2b0d7b3dcb6d。它由 32 个十六进制字符和 4 个连字符组成。放在文本流里，它就是一连串“没有空格分隔”的连续字符。浏览器在处理连续英文字符时，默认的换行规则很保守：只有在空格、连字符或标点等断点位置才允许折行。所以 UUID 在文本里看起来就有两个问题——要么整块“梗”在容器里不换行，把容器撑出横向滚动条；要么在某个不理想的位置强行断开，读起来完全失去分组感。

我们平时处理普通中文文本时基本不会遇到这种问题，因为中文每个字之间天然就是可行的断点。但 UUID 这类 token、编号、哈希值、序列号有个共同特点：无空格、无自然语义分组、纯字母数字密集排列。它们一旦出现在表格列、详情页、卡片标题、日志前缀、导出表格里，布局问题就会集中暴露。

这里先给一个生活化的类比。想象你把一长串英文单词去掉所有空格写成一整行，比如thisisalongenglishsentencewithoutanyspaces，浏览器在遇到这种文本时拿它一点办法都没有。它要么全部换行到底，要么干脆超出容器。UUID 本质上是“32 个随机十六进制字符 + 4 个连字符”的组合，比这个类比还难处理，因为它连单词之间的空格都没有。

这篇文章就把这个看似小到不起眼、但几乎每个开发都会碰到的“UUID 文字换行处理”问题系统性拆一遍。我会覆盖三条主线：基础 CSS 换行属性的正确选择、表格和卡片等具体场景的处理姿势、以及比“换行”更进一步的显示层优化方案。最后还会顺手聊几个和 UUID 相关的高频问题——比如“UUID 能不能当登录 token”“UUID 太长了有没有精简方案”这些。全程用代码示例加踩坑记录的方式，让无论你是前端新手还是全栈老手，都能直接拿去用。

2. 三类 CSS 换行方案，到底该用哪个

2.1 三个核心属性的本质区别

先明确一组概念：处理连续英文字符串换行，常用的 CSS 属性有三个。word-break: break-all、overflow-wrap: break-word（老写法叫word-wrap: break-word）和overflow-wrap: anywhere。很多人分不清它们，网上复制粘贴的代码也常常张冠李戴。我先把它们的行为差异讲清楚。

word-break: break-all是最“暴力”的方案。它的语义是：在任意字符之间都可以断行，不需要考虑单词完整性。对于 UUID 来说，只要空间不够，字符就直接断开，连字符依然作为普通字符保留，断行位置可以是任何数字和字母之间。这种方式的优势是彻底解决溢出，副作用也是一眼可见的：它会破坏所有“英文单词”的正常断行。假如单元格里除了 UUID 还有一行完整的英文描述，比如transaction completed successfully，在break-all的作用下，单词transaction可能变成transactio加n两段，阅读体验非常差。所以它适合那种“列里只有编号没有英文文案”的极简场景。

overflow-wrap: break-word的默认语义则完全不同。它只在“一个完整单词超出容器宽度、且不换行就会溢出”时才允许断开。注意这个“才”字——浏览器先尝试在空格处断行，实在不行才在单词内部断。对 UUID 来说，由于它本身是一个没有空格的“长单词”，在容器宽度不足时它也会被断开。它和break-all的核心区别在于：如果 UUID 本身能完整放得下，它绝不在中间硬拆，而break-all无论能不能放下都可能在任意位置找机会断——即使宽度充足，多行布局时它也可能把 UUID 拆得稀碎。

overflow-wrap: anywhere从行为上跟break-word很像，但它额外影响一个关键机制：断行能力参与最小内容尺寸（min-content size）的计算。这句话很拗口，我直接用例子说明。在一个 flex 容器或 grid 网格里，如果子项的文字长到超出所有可用宽度，break-word不会强制压缩容器的固有宽度，而是允许文字溢出后再断开；anywhere则会把可断行能力计入容器的基础尺寸计算，让容器优先收缩到合适宽度，而不是先溢出再换行。

这三个属性的差异我用一个表格总结，方便大家对照实际场景挑选：

2.2 三个极简示例看清真实行为

我写三个最小示例来展示实际效果。假设容器宽度是 200px，里面放同样的 UUID：9b1deb4d-3a7d-4bad-9bdd-2b0d7b3dcb6d。

第一种情况，什么都不加。容器宽度不足时，UUID 作为一个完整单词会整体下沉换行，如果它长度还是超过 200px，就直接溢出横向滚动条。这是默认行为。

第二种情况，加上：

.uuid-cell { word-break: break-all; }

效果是 UUID 在容器的右边缘任意字符处直接断开，第二行接着往下显示。视觉上比较乱，数字在字符正中间断开不太美观，但至少不会溢出。

第三种情况，加上：

.uuid-cell { overflow-wrap: break-word; }

效果同样是折行，但断行逻辑保留了连字符这个特殊断点。虽然没有严格保证“一定从连字符处断开”，但浏览器会优先在连字符位置断，如果连字符前的部分仍然太长，才能在字符中间断开。从实测结果看，UUID 在连字符后断开的情况明显更多，可读性比break-all好很多。

2.3 我的选择建议

我的默认方案是：在绝大多数 UI 场景中用overflow-wrap: break-word，不要用word-break: break-all。原因很简单：UUID 的显示问题本质是“在不完美的条件下尽量保持可读性”，break-word的保守断行策略能最大程度保留十六进制块的分组感。

word-break: break-all只留给两种场景：一是纯机器读取的日志流，无所谓人类是否容易阅读；二是列宽度极小、内容只有编号且需要最大化利用空间的表格。而overflow-wrap: anywhere主要在 flex 和 grid 布局里控制收缩行为时使用，比如侧边栏卡片里放订单号、移动端列表项里放设备 ID，用来避免“因为长文本导致子项宽度超出预期”的问题。

注意：设置overflow-wrap时，老的word-wrap写法仍然有效，但规范推荐统一使用overflow-wrap。写代码时保持一种写法，不要混用。

3. 表格中的 UUID 换行，正确姿势不是只要一个属性

3.1 表格布局固化是关键前提

后台管理系统里最常出现 UUID 的地方就是表格列——订单号列、支付流水号列、设备 ID 列、操作日志 ID 列。这些列的问题不光是“长文本折行难看”，更折磨人的是不同行的 UUID 长度一致、内容随机，导致明明设置了列宽，实际渲染出来却宽窄不一。

很多人以为给单元格加上word-break: break-all就万事大吉，结果是列宽被内容撑开、表头错位、横向滚动条出现。这里我分享一个真实有效的组合方案。

第一，给表格设置table-layout: fixed并且给表格一个明确的总宽度或width: 100%。它的原理是：浏览器不再根据每个单元格的内容自动计算列宽，而是完全按照你设置的表头和列宽规则分配空间。这样 UUID 再长，也不会反过来把列撑爆。

第二，对 UUID 列设定一个合理的宽度。这个宽度取决于你想要展示多少位字符。如果只显示前 16 位加省略号，列宽可以设小一点；如果显示全量，列宽要足够容纳折行后的宽度。我一般习惯把 UUID 列宽度设在 220px 到 280px 之间，这样全量显示时大约两行到三行就能放下。

第三，在单元格上叠加overflow-wrap: break-word，保证在固定列宽的限制下能优雅断行。

.uuid-table { width: 100%; table-layout: fixed; } .uuid-table .uuid-column { width: 240px; overflow-wrap: break-word; }

3.2 表头与单元格的配合细节

table-layout: fixed有一个副作用：如果表头里的标题也是长文本，它也会被压缩到同样宽度。所以表头一般用简短标签，比如“订单号”而不是“交易系统全局唯一标识符”。同时，表头建议加word-break: keep-all，防止“订单号”这种短词被拆分，保持表头整洁。

另一个容易忽略的点是表格容器本身。建议在用min-width: 0处理表格外层元素。在 flex 布局中，如果表格外层是display: flex的容器，子元素默认有min-width: auto，这意味着即使你设置了table-layout: fixed，外层 flex 项也可能因为内容撑开宽度而不收缩。这个min-width: 0是解决 flex 子项溢出问题的重要一步，日常布局中非常多见。

提示：如果 UUID 需要展示在弹窗或抽屉里，弹窗容器也建议检查是否设置了 overflow 相关的限制。弹窗内层嵌套复杂时，可能需要在弹窗内容区设置min-width: 0并确保宽度是百分比而不是固定像素，否则易出现“弹窗宽度自动变大，却把遮罩层撑满”的诡异现象。

3.3 打印与导出场景要“一列多用”

如果你的表格还支持打印或者导出 PDF，处理逻辑又不一样。打印时页面宽度是 A4 纸的固定物理宽度，列宽不能再随便排。最佳实践是：打印时把 UUID 列宽度放大到整个表格的 40% 左右，其余列压缩，同时启用overflow-wrap: anywhere。因为打印浏览器对断行的计算与屏幕浏览器存在差异，anywhere能更稳妥地保证内容不超出纸质页面。

导出 CSV 或 Excel 时，表格展示的换行逻辑完全失效。导出文件里 UUID 是完整字符串，Excel 对超长数字和字母串有时会显示为科学计数法，但 UUID 内含有字母和连字符，一般不会触发。需要注意的是：导出时不要把界面上的省略号文案带出去，必须导出完整 UUID。这个坑我踩过，之前为了页面美观，列表里只展示了 UUID 后四位，导出报表时直接把截断后的字符串导出成文件了，最后对账对不上，查了半天才发现是导出逻辑直接读了页面显示字段。

4. 不只是换行：UUID 显示层的更多优化

4.1 截断显示，把 36 位变成舒服的 8 位

换行处理只是让 UUID“放得下”，但很多时候我们连让它折行都不愿意——太丑了。更常见的思路是：默认只显示部分字符，把全量信息放到悬浮、点击或复制操作里。

最简单的做法是截前 8 位。很多系统展示设备 ID 时只显示前 8 位加省略号，比如9b1deb4d...。如果担心前 8 位会重复，可以截前 8 位加后 4 位，比如9b1deb4d-b3dcb6d。这个长度既有辨识度，又几乎不会因为重复造成混淆，在订单号列表中完全够用。

但截断显示有一个体验问题：用户没办法在列表里直接看到完整 UUID。所以需要配套一个复制按钮。我做了一个小组件，展示截断字符串，旁边放一个复制图标，点击后复制完整 UUID，并给出一个轻提示“已复制”。这个方案的交互非常干净，列表也清爽。

实现上只需要两个字段：一个用于展示的displayId，一个用于复制或跳转的fullId。建议后端接口直接返回完整 UUID，由前端负责截断展示。这样导出、详情、复制都基于同一个字段，避免前后端不一致。

4.2 显示中间省略号比末尾省略号优雅得多

如果非要展示较多字符，但又有省略需求，常规的text-overflow: ellipsis只能做单行末尾省略。可 UUID 的随机性意味着前几位和后几位才是用户最需要的辨识信息，末尾省略会把后四位一起省略掉，用户想对比尾部数字时还得点开看。

行业里有种做法叫“中间省略”，效果类似9b1deb4d-...-b3dcb6d。实现上不需要复杂算法，最简单的方式是用两个 span，各自设置text-overflow: ellipsis，再配合 flex 布局。左侧 span 负责截前半段，右侧 span 负责截后半段，中间手动写一个省略号。

<span class="uuid-mid-ellipsis"> <span class="uuid-prefix">9b1deb4d-3a7d-4bad-9bdd</span> <span class="uuid-ellipsis">...</span> <span class="uuid-suffix">0b7d3bdcb6d</span> </span>

.uuid-mid-ellipsis { display: flex; max-width: 280px; } .uuid-prefix { overflow: hidden; white-space: nowrap; text-overflow: ellipsis; flex-shrink: 1; } .uuid-ellipsis { flex-shrink: 0; } .uuid-suffix { flex-shrink: 1; overflow: hidden; white-space: nowrap; text-overflow: ellipsis; }

这段代码的思路是：左右两段各自在超出宽度时省略，中间省略号固定不动。比传统的“拿字符串在 JS 里算长度再拼接省略号”的方案更省事，也更稳定，因为它的宽度判断是浏览器实时计算的，不会因为容器宽度变化而失效。

注意：中间省略方案需要外层容器有明确的最大宽度或宽度约束。如果外层宽度不固定，所有内部省略逻辑都不会生效。

4.3 可控断点方案：让 UUID 在连字符处断开

回到“换行”本身，还有一个容易被忽略的优雅技巧：使用<wbr>标签或零宽空格​在 UUID 的连字符处插入可选断行点。这样一来，浏览器在空间不足时会优先在连字符后面断开，而不会在十六进制字符中间硬切。

比如：

<span class="uuid-text">9b1deb4d-<wbr>3a7d-<wbr>4bad-<wbr>9bdd-<wbr>2b0d7b3dcb6d</span>

效果是：当容器宽度足够时，UUID 保持单行完整显示；当宽度不够时，断行只发生在 4 个连字符后，每一行都是完整的“块”，阅读体验非常好。配合overflow-wrap: break-word使用，几乎可以达到“只在连字符处断行”的理想效果。

但要注意兼容性。<wbr>在旧版 IE（IE 8/9）中支持不佳，现代浏览器都支持。如果你需要兼容到老环境，可以使用零宽空格​代替。不过零宽空格在某些自动化测试和复制粘贴场景中会留下不可见字符，导致 UUID 直接编码后带入了隐藏符号，后端解析失败。我的经验是：如果项目需要把页面中显示的 UUID 复制出来再次使用（比如粘贴到搜索框或日志系统），宁可多写一个 JS 方法在前端渲染时动态插入<wbr>，也不要用零宽空格方式，避免隐藏字符引发问题。

5. 高频 UUID 问题：精简方案、Token 使用、分布式场景

5.1 UUID 太长了，到底有哪些精简思路

这其实是“UUID 换行问题”背后一个更深层的需求。既然 UUID 不好排，为什么不直接用短一点的东西呢？精简方向常见的有三种。

第一种：存储层精简。UUID 字符串占用 36 个字符，但在大多数数据库中可以用 16 字节的二进制格式（BINARY(16)）存储，查询时再转为字符串显示。像 PostgreSQL 有原生的uuid类型，MySQL 可以用UNHEX(REPLACE(uuid, '-', ''))压缩存储。这能节省一半以上的存储空间，但显示层依然要处理字符串换行问题——所以这只是解决了存储，没有解决展示。

第二种：ID 生成策略精简。如果你在分布式系统里需要全局唯一 ID，完全可以用更短的方案代替 UUID v4。常见的包括 Snowflake ID（雪花 ID）及其变种，它生成的是一个 64 位长整数，转成十进制通常只有 18 到 19 位数字。相比 36 位 UUID，字符数减少一半，而且天然适合作为数字类型存储，索引性能也更好。另有各种“短 UUID”库，把 128 位 UUID 重新编码为 22 个字符的 Base64 形式，比原来的 36 位短不少。

第三种：业务逻辑精简。如果 ID 只需要在单库单应用内唯一，直接用数据库自增 ID 或 Redis 的 INCR 生成连续数字 ID 就够。这类 ID 短、无序、适合排序，但也意味着对外可枚举——如果你的 ID 用在公开场景，需要额外加权限校验。

我个人的建议是：做内部系统、且接口只面向可信后端，用自增 ID 或雪花 ID 都行；做高并发分布式系统、且要求各节点无协调生成全局唯一 ID，直接用 UUID v4 配合二进制存储；做对外暴露的接口路径、且担心遍历攻击，那么不管用 UUID 还是雪花 ID，都要在服务端做鉴权和限流。

5.2 UUID 能当登录 Token 用吗

看到“uuid 能当登录 token”这个热搜词，忍不住多说一句。UUID 只是一个全局唯一标识符，它保证的是不重复。而登录 token 的核心要求是：不可伪造、可撤销、有过期时间、服务端能验证。UUID v4 的随机特性让它具有一定“不可预测性”，但登录凭证还需要关联用户身份、会话生命周期等信息。如果直接把 UUID 当登录凭证，服务端至少还得把 UUID 和用户 ID、过期时间存在一张表里，其实你已经做一个简化版的 session 系统了。

所以从工程上讲，能用，但不推荐裸用。更合理的做法是拿 JWT 这类自带签名和过期机制的 token，或者生成一个随机 session id 后，把用户身份、过期时间存在 Redis 中。UUID 本身的随机性和唯一性可以用于生成 token 的核心随机部分，但不要把它整个当作 token 的全部内容。这个思路跟 UUID 的换行处理也有关系——如果 token 也是长字符串，它同样会遇到前端展示时需不需要折行的问题，这里用上面讲的 CSS 方案完全可以覆盖。

5.3 分布式 UUID 的展示细节

在分布式系统中使用雪花 ID 或 UUID 时，还有一个容易忽视的细节：ID 的可读性。雪花 ID 带有时间戳和机器号的信息，虽然肉眼很难解码，但其前缀往往具有递增规律，排列表格时可以按 ID 排序得到近似创建时间的顺序。而 UUID v4 是完全随机的，无法从 ID 本身判断时间先后。

如果业务系统里需要根据 ID 展示时间维度，不要把顺序判断的期望放在 UUID 上，一定要单独存一个created_at字段。很多人在列表页想“按 ID 倒序排”，结果拿到 UUID 排序后得到的时间序列完全错乱，这个坑比换行问题隐蔽得多。

另外，在日志系统里打印分布式 UUID 时，建议统一使用小写形式。虽然 UUID 本身不区分大小写，但不同服务生成时可能大小写风格不一致，混用到日志检索里很容易漏掉数据。显示层处理 UUID 时也建议先做一次toLowerCase()，保证前端样式和日志检索条件的统一。

6. 常见问题与排查技巧实录

6.1 为什么加了 word-break 表格还是被撑宽

这是一个很典型的误用场景。有人在表格单元格上加word-break: break-all，但表格列宽还是被撑开了。排查后发现问题出在两层：第一，表格没有启用table-layout: fixed，浏览器依然根据内容自动决定列宽；第二，单元格内的子元素可能是一个div或者带display: inline-block的元素，word-break作用在外层单元格上，内层inline-block的内容却不受控。

正确做法是：把换行属性直接设到最内层的内容容器上，同时在表格上设置固定的布局算法。检查时优先确认，你要控制的到底是单元格本身还是单元格内部的某个 span、p、div。这条我至少帮同事排查过三四次，每次都是 DOM 层级没选对。

6.2 复制 UUID 时带上了隐藏字符

之前被坑过一次。页面显示 UUID 时为了“优雅折行”，我用了零宽空格​方式插入断点。用户在列表里复制 UUID 粘到终端查询时，字符串里混入了不可见字符，服务端匹配不上。排查了半天，最后用十六进制查看器才发现中间多了U+200B字符。

从此之后，我总结出两条铁律：如果这个 UUID 需要被用户复制或回传，绝不用零宽空格做断行处理，改用<wbr>（或干脆换行属性方案）。如果是系统内部读取页面上的 UUID 做二次操作，绝不要直接读 DOM 上的文本内容，而要读取数据层里的 fullId 字段。

6.3 类似字符串场景的通用排查思路

UUID 的换行处理方案同样适用于其他类似字符串：订单号、优惠券码、签名串、哈希值、证书序列号、BLE 设备的 GATT UUID、iOS 设备的 UDID 等。这类字符串的共同特点是长、无空格、含连字符或点号。遇到它们，我的排查顺序是：

1. 确认容器宽度是否被正确约束（是否设置了 width / max-width / flex-basis，外层是否被内容撑开）。
2. 确认换行属性设置在哪一层，是否作用到了最内层文本节点。
3. 确认是否启用了white-space: nowrap——如果有这个属性，所有 word-break 和 overflow-wrap 的设置都会失效，这是最常见的隐形问题。
4. 检查是否存在text-overflow: ellipsis与多行显示的冲突。
5. 如果在表格中，先解决表格布局算法，再解决单元格内的断行问题。

6.4 一个综合参考模板

下面是我在实际项目里常用的“UUID 单元格”组合模板，贴出来给需要直接抄作业的人。

.uuid-column { width: 240px; min-width: 0; overflow-wrap: break-word; word-break: normal; line-height: 1.5; font-family: "SFMono-Regular", Consolas, "Liberation Mono", Menlo, monospace; font-size: 13px; color: #444; }

HTML 结构部分：

<div class="uuid-wrapper" style="display: flex; align-items: center; gap: 8px;"> <span class="uuid-column" id="orderIdText">9b1deb4d-...</span> <button type="button" onclick="copyFullId('orderFullId', this)">复制</button> </div>

配合 JS 复制方法：

function copyFullId(id, btn) { const fullId = document.getElementById(id).dataset.fullId; navigator.clipboard.writeText(fullId).then(() => { btn.textContent = '已复制'; }); }

这套方案里，展示文本由前端截断，完整 UUID 放在隐藏元素或 data 属性中，复制按钮与展示解耦。既避免了长字符串的排版问题，也保证了数据的完整性。

7. 移动端和多端适配的几个补充细节

移动端处理 UUID 显示和桌面端略有不同。手机屏幕窄，可用宽度通常只有 320 到 390px，全量展示 UUID 意味着必然折行，而且折行后行数可能达到 4 到 5 行。这时候我的建议是：移动端一律默认截断展示，只显示前 8 位或前 8 位加后 4 位，把完整 UUID 放入复制按钮或详情页。列表页保持单行简洁，详情页才允许完整展示。

触屏场景还有一个特殊交互问题：长按文本选择复制时，如果 UUID 在多行折行，iOS 上的一次性矩形选区和换行后的文本之间经常会出现选区错乱。用户在手机上想复制完整 UUID，结果多选或少选了一段。为了避免这种情况，移动端列表里的 UUID 文本最好设置display: inline-block且white-space: nowrap，再配合截断方案让它保持单行。这样长按选中时选区更加稳定。

转义字符方面，如果项目使用 Vue 或 React，渲染 UUID 时建议直接写成{{ fullId }}，让框架自己处理转义，不要在模板里拼 HTML 字符串。动态拼接的 HTML 节点里插入<wbr>容易导致 XSS 或转义错误，能用框架组件解决就尽量别用dangerouslySetInnerHTML或v-html。

小程序和 App 端的 WebView 里，CSS 换行属性的支持情况整体一致，但个别 Android WebView 内核版本对overflow-wrap: anywhere的支持有差异。如果遇到适配问题，回退方案是word-break: break-all加overflow-wrap: break-word同时写上，确保旧内核也能正常断行。

8. 几个我后来才想明白的经验

做完了这个“小问题”之后，回头想想，其实有几个项目层面的经验比具体 CSS 代码更值得分享。

第一，处理任何“长字符串显示”问题，先想清楚这个字符串最终用途是什么。如果它要被系统读取、被用户复制、被接口回传，那就不能为了视觉效果牺牲数据完整性。省略号方案、中间截断方案、零宽空格方案，全都只能在展示层用，绝对不能污染底层数据字段。

第二，显示细节是产品体验的一部分，别小看一个换行。UUID 列表在后台管理系统里是高频操作区域——运营要对比订单号、技术要查流水号、客服要确认设备 ID。一个乱糟糟的折行列表，会让人的视线反复跳跃，长时间使用非常疲劳。把 UUID 显示做成“一眼能定位、复制不出错”，对用户效率的提升非常明显。

第三，遇到类似“UUID 换行”这个标题级的问题时，单点解决只是第一步。更好的做法是抽出一个通用组件，把这个字符串的展示、截断、复制、悬浮提示、隐藏全量值等能力打包起来，后续所有业务页面直接复用。组件里预留自定义插槽，让调用方决定显示长度、是否显示复制按钮、截断样式。这样就可以一劳永逸，之后凡是订单号、设备码、签名串都能直接套用。

拿我个人习惯来说明，我在组件里通常会暴露三个配置项：value（完整字符串）、visiblePrefix（展示前缀字符数，默认 8）、visibleSuffix（展示后缀字符数，默认 4）。如果两个都为 0，就代表全量展示；如果只配前缀，则显示前 N 位加省略号；前缀后缀都配，则显示中间省略格式。内部渲染逻辑统一走 CSS 方案，数据值始终从value读取，展示截断只发生在 render 阶段。

写到这里，UUID 从换行到显示再到数据完整性的整个链路基本过了一遍。我最后再分享一个小技巧：如果你在做一个会长期维护的后台系统，建议在全局 CSS 里统一给所有“ID 类文本”建立一个公共类名，例如.id-text，把font-family定为等宽字体、overflow-wrap: break-word、min-width: 0等基础属性都放进去。这样后面新来的人在追加表格、卡片时，只要下意识给 ID 字段加上这个类名，就不会再出现“字符串撑爆布局”的经典事故。这个习惯帮我省了非常多琐碎的排期修复时间。