企业官网建设流程全解析

不知道你有没有遇到过这种情况：一个输入框，明明设置了maxlength="10"，但输入 5 个汉字就再也打不进去了；或者一个表格列，明明写好了width: 200px，可中英文混排时仍然会在奇怪的换行点断开；又或者你在终端里打印表格，英文对齐得整整齐齐，一出现中文，整列就全乱了。

这些问题的背后，大多数时候都和同一个概念有关：字符宽度。

很多人第一反应是“字符宽度不就是 CSS 的width吗？”其实不是。在真实开发中，字符宽度会牵扯到字符集、全角半角、字体渲染、后端存储、终端显示等多个层面。同一个词“宽度”，在浏览器、数据库、终端和 Canvas 里，含义完全不一样。理解这一点，才能真正把布局、校验、对齐做好。

这篇文章会从几个实际开发场景出发，把“字符宽度如何正确设置”这件事拆开讲清楚：

• 前端页面里如何用 CSS 控制文本显示宽度；
• 输入校验时如何按“视觉宽度”而非“字符个数”计算；
• 数据库里字段长度到底该按什么单位设置；
• 终端和 Canvas 中如何测量真实像素宽度。

尽量做到一边讲原理，一边给出可直接复制的代码，遇到坑也能快速定位。

1. 这篇文章真正要解决的问题

在之前帮团队做内部系统时，我见过太多和字符宽度相关的 Bug。比如运营同学在后台录入活动标题，要求最多显示 20 个汉字，但有些标题里混了英文、数字和全角括号，测试时怎么截断都不对劲。用substring(0, 20)截，英文倒是能截，可中文截到一半就会出现乱码；用 CSSmax-width限制吧，不同字体下同一个字符串占的像素宽度又不一样。

再比如另一个项目里，后端给前端返回了一个超长字符串，前端在表格里显示时，默认把单元格撑得老宽，导致整张表失去平衡。当时有人提议“给所有单元格固定宽度”，结果一到中文和英文混排的列，文字要么溢出，要么被切得支离破碎。

这些问题表面上是“样式问题”，实际上都指向一个核心认知：字符宽度不是一个固定值，它取决于编码、字体、渲染环境和计算方式。如果你只用一个维度去处理，必然会在另一个维度上出问题。

读完这篇文章，你会得到几个具体收益：

1. 搞清楚“字符个数、视觉宽度、字节长度”三者的区别，不会再混淆。
2. 前端布局时知道该用px、ch、em还是max-width来控制文本显示。
3. 写中英文混排校验时，能按真实显示宽度计算，而不是用length()数完就完事。
4. 数据库字段长度和字符集配置时，不再被“255”这种经验值坑到。
5. 在终端、Canvas 等场景下，能准确测量字符串宽度并做对齐。

2. 基础概念与核心原理

要理解字符宽度，先要把三个经常被当成一回事的概念拆开：字符个数、字节长度和视觉宽度。

2.1 字符个数

字符个数就是字符串里有多少个字符。在 JavaScript 中可以用length，在 Python 中可以用len()。但要注意，Unicode 里有组合字符、emoji、代理对等情况，字符串.length返回的结果不一定等于用户感知的“字的数量”。比如"👨‍👩‍👧‍👦"在 JavaScript 里length很可能返回 11，因为它是多个码点组合成的。这一点虽然不是字符宽度问题的核心，但在做输入校验时会踩坑。

2.2 字节长度

字节长度是字符串在特定编码下占用的存储空间。同样是汉字“中”，在 GBK 编码里占 2 字节，在 UTF-8 编码里占 3 字节。而英文字母A在 UTF-8 里只占 1 字节。如果后端使用 MySQL 的VARCHAR(255)，这个 255 默认是指字符数，不是字节数。但如果在某些老系统里用了VARCHAR2(255 BYTE)（Oracle），那么它能存的中文字符数就会明显少于 255。

这就是为什么同一段逻辑，有人按“长度”验，有人按“字节”验，结果总是对不上。

2.3 视觉宽度

视觉宽度，才是用户真正看到的宽度。它取决于字体渲染。在等宽字体（如Consolas、Courier New、很多 IDE 默认字体）里，英文字母和数字通常宽度相同，中文汉字一般是英文的两倍宽。在比例字体（如系统默认的中文字体、微软雅黑、宋体）里，不同英文字母的实际像素宽度也不一样，W就比i宽很多。

因此，所谓“字符宽度”在最底层其实是“一个字形的度量值”，通常由字体文件中的advance width决定。排版引擎拿到字体后，会根据字号、缩放、字间距计算出一段文本的实际像素宽度。

下面用表格总结这三种概念的区别：

2.4 全角与半角

在中文文本处理中，全角半角是一个躲不开的概念。

• 半角字符：ASCII 范围内的英文、数字、常见英文符号，在等宽字体下通常占 1 个字符宽度。
• 全角字符：中文汉字、日文假名、韩文谚文，以及全角标点（如，、。、“”），通常占 2 个字符宽度。

Unicode 里有一些字符同时存在全角和半角形式，比如英文字母全角Ａ和半角A，数字全角１和半角1。它们显示宽度不同，但在某些系统中如果不做归一化，会把看起来差不多的内容当成两个不同的字符串，这也是数据清洗时的常见问题。

2.5 等宽字体下的字符宽度

终端、编辑器、代码块里常用等宽字体。在等宽字体下，A和i的宽度一致，这保证了代码对齐。但是中文字符通常还是会占据两个英文字符的宽度，或者在某些字体下并不严格等于 2，而是由字体设计者决定。所以做终端表格对齐时，不能简单用len()来补空格，而要考虑“显示宽度”。

3. 前端页面中如何正确设置字符宽度

如果你打开浏览器 DevTools，选中一个元素看它的 Computed 样式，会发现所有文本最后都会被排版引擎转换成一个盒子的宽高。CSS 的width、max-width、min-width、word-break、overflow等属性共同决定文本最终如何呈现。

但这里有一个关键认知：CSS 的width是作用于元素盒子的，不是作用于字符的。一个width: 200px的容器，能放下多少个字符，取决于字号、字体、字符串内容，而不是你把 width 设成多少，字符就按规定宽度排布。

3.1 用ch单位近似控制字符数

CSS 中有一个单位叫ch，它的定义是“字符 0”的宽度。这个单位在等宽字体中特别好用，因为等宽字体里所有英文字母和数字宽度一致，1ch就近似等于 1 个字符的宽度。

/* 文件路径：styles/char-width.css */ .code-output { font-family: "JetBrains Mono", Consolas, monospace; font-size: 14px; width: 40ch; /* 在等宽字体下，约等于 40 个英文字符宽度 */ overflow-x: auto; white-space: nowrap; }

这段样式适合代码输出、日志展示等场景。只要字体是等宽字体，40ch就能稳定地控制容器宽度，不会因为字符串内容不同而忽宽忽窄。

但要注意：ch依赖当前元素的计算字号和字体。如果字体不是等宽字体，1ch只是字符0的宽度，不代表其他字符的平均宽度。中文在ch单位下的表现也因字体而异，通常一个汉字会大于1ch，大约接近2ch，但严格来说并不精确。

3.2 用max-width处理长文本截断

在实际界面里，我们通常不希望文本把容器撑爆，而是希望它在一个范围内自动换行或截断。典型场景是列表标题、卡片摘要、表格单元格。

/* 文件路径：styles/text-clamp.css */ .card-title { max-width: 280px; white-space: nowrap; overflow: hidden; text-overflow: ellipsis; } .card-desc { display: -webkit-box; -webkit-box-orient: vertical; -webkit-line-clamp: 2; line-clamp: 2; overflow: hidden; }

第一段代码实现单行省略号，适合标题类文本。第二段代码实现两行截断，适合摘要类文本。但这里有个容易被忽略的点：max-width: 280px只是一个经验值，它不保证刚好放下 10 个汉字。如果标题在某种字体下比较宽，可能只显示 9 个汉字就出现省略号；在另一种字体下，可能能显示 11 个。

要真正精确控制，应该用 JavaScript 动态测量文本宽度，再决定如何截断，而不是完全依赖 CSS 的固定宽度。

3.3 输入框和文本域如何限制输入宽度

很多产品需求是“标题最多输入 20 个汉字”，但用户可能输入英文、数字、半角括号。如果按字符数限制，20 个英文字符在界面上显示起来很短，视觉上不对称；如果按maxlength限制，中英文混排时又会很快触顶。下面给出一个前端按“视觉宽度”限制输入的最小方案，后面解释具体实现。

4. 中英文混排的宽度计算与输入校验

先说结论：在中英文混排场景下，不要用字符串.length作为“显示宽度”的唯一依据。更好的做法是给每个字符设一个宽度权重，然后累计求和。

4.1 为什么length不够用

假设产品要求“输入框最多显示 20 个字符的视觉宽度”。如果用户输入：

Hello CSDN!

这句一共 11 个 ASCII 字符，视觉宽度约等于 11。如果用户输入：

你好CSDN

从显示上看，“你”“好”比英文宽，大约等于 4 个英文宽度加 4 个英文宽度。而length()返回 6，如果按 6 去判断是否超过 20，显然和用户看到的宽度不一致。

更麻烦的是全角标点。，、。、“”在中文排版中占两个字符宽度，但它们的length同样是 1。如果系统只统计字符个数，很容易出现“显示上已经很长了，但逻辑上还没超限”的情况。

4.2 按显示宽度计算的 JavaScript 实现

常见的近似算法是：ASCII 可见字符、部分标点和空格记为 0.5 或 1，中文、全角字符、emoji 记为 2，甚至更多。下面用一个综合函数实现“显示宽度”的计算，并支持按宽度截断字符串。

// 文件路径：utils/charWidth.js /** * 计算字符串的显示宽度（近似值） * 规则： * - 常见全角字符（中文字符、全角标点）按 2 计算 * - 其他字符按 1 计算 * - 组合字符、emoji 需要额外处理 * @param {string} str * @returns {number} */ function getDisplayWidth(str) { const fullWidthRegex = /[\u1100-\u115F\u2E80-\uA4CF\uAC00-\uD7A3\uF900-\uFAFF\uFE10-\uFE19\uFE30-\uFE6F\uFF00-\uFF60\uFFE0-\uFFE6]/; let width = 0; for (const ch of str) { // 遍历的是 Unicode 码点，而不是 UTF-16 代理对 if (fullWidthRegex.test(ch)) { width += 2; } else { width += 1; } } return width; } /** * 按显示宽度截断字符串，超出部分用省略号替代 * @param {string} str * @param {number} maxWidth * @param {string} ellipsis * @returns {string} */ function truncateByWidth(str, maxWidth, ellipsis = '...') { const ellipsisWidth = getDisplayWidth(ellipsis); let width = 0; let result = ''; for (const ch of str) { const chWidth = getDisplayWidth(ch); if (width + chWidth + ellipsisWidth > maxWidth) { return result + ellipsis; } width += chWidth; result += ch; } return result; } export { getDisplayWidth, truncateByWidth };

上面用for...of遍历字符串，能按 Unicode 码点切开字符串，避免"👨‍👩‍👧‍👦"被切成半个代理对。正则里覆盖了 CJK 统一汉字、谚文、全角符号等常见区域，基本能覆盖中英文混排场景。

然后在前端输入框里，可以这样使用：

// 文件路径：components/LimitedInput.vue（示例为 Vue 3 组合式风格） import { ref, watch } from 'vue'; import { getDisplayWidth, truncateByWidth } from '../utils/charWidth'; export function useLimitedInput(maxDisplayWidth = 20) { const inputText = ref(''); const displayWidth = ref(0); function handleInput(value) { if (getDisplayWidth(value) > maxDisplayWidth) { inputText.value = truncateByWidth(value, maxDisplayWidth); } else { inputText.value = value; } displayWidth.value = getDisplayWidth(inputText.value); } return { inputText, displayWidth, handleInput }; }

这里的关键是：输入校验从“长度限制”变成了“宽度限制”。无论用户输入中文还是英文，最终控制的是视觉宽度，符合产品预期。

4.3 边界情况：emoji 和组合字符

上面代码对 emoji 的处理还不够精细。👨‍👩‍👧‍👦这类 emoji 由多个码点组成，遍历每个码点时，它们大多落在“其他字符”分支，最终宽度会被算成多个 1，但实际渲染时它可能是一个大符号，显示宽度甚至超过普通汉字。

如果产品要求严格贴合渲染结果，建议直接使用 Canvas 测量，或者使用成熟库，比如string-width（Node.js 生态）来计算 East Asian Width。在浏览器端也可以直接用 CanvasmeasureText，这一点放在后面的 Canvas 部分说。

5. 数据库与后端存储的字符宽度设置

字符宽度的问题不仅存在于前端显示层，在后端存储时同样要小心。很多接口异常、数据库报错，本质上是因为“宽度”理解不一致。

5.1 MySQL 的 VARCHAR 长度单位

在 MySQL 中：

• VARCHAR(100)的 100 表示字符数，不是字节数。
• 在 utf8mb4 字符集下，一个汉字大约占 3 字节，emoji 占 4 字节，因此VARCHAR(100)最多能存 100 个汉字，但可能占用 300 字节。

如果你在 JDBC 连接串里看到characterEncoding=utf8，在 MySQL 5.7 之后通常代表的是utf8mb3，无法完整存储 emoji。这也是很多项目把utf8改成utf8mb4的原因。

5.2CHAR_LENGTH和LENGTH的区别

后端排查字符串超限问题时，常用到这两个函数：

SELECT title, CHAR_LENGTH(title) AS char_len, LENGTH(title) AS byte_len FROM article WHERE id = 1;

CHAR_LENGTH返回字符数，LENGTH返回字节数。在 utf8mb4 下，LENGTH('你好')返回 6，而CHAR_LENGTH('你好')返回 2。

如果业务需求是“标题最多输入 20 个汉字的宽度”，最接近的字段定义可以是VARCHAR(20)，但要注意 20 个全角字符不一定等于 20 个视觉宽度，因为有些全角标点虽然占两个显示位置，但在字符层面只算 1。所以在后端，最可靠的方式是：

1. 按前端校验后的宽度结果提交。
2. 后端做二次校验，但校验规则和前端保持一致。
3. 存储层按“最大汉字数”或“最大字符数”设长度，而不是按字节盲猜。

5.3 一条建表与校验示例

下面是一个小型文章表的结构和简单的后端校验伪代码：

CREATE TABLE article ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(50) NOT NULL COMMENT '标题，最多 50 个字符', summary VARCHAR(200) NOT NULL COMMENT '摘要，最多 200 个字符', content MEDIUMTEXT, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

// 文件路径：src/main/java/com/example/demo/ArticleValidator.java public class ArticleValidator { /** * 使用 ICU4J 或正则近似计算显示宽度 * 这里仅示范思路：字符数 + 全角宽度加权 */ public static int getDisplayWidth(String input) { if (input == null) { return 0; } int width = 0; for (int i = 0; i < input.length(); i++) { char c = input.charAt(i); if (c >= '\u1100' && c <= '\u115F') { // 谚文 width += 2; } else if (c >= '\u2E80' && c <= '\uA4CF') { // CJK 部首、汉字等 width += 2; } else if (c >= '\uAC00' && c <= '\uD7A3') { // 谚文音节 width += 2; } else if (c >= '\uF900' && c <= '\uFAFF') { // CJK 兼容汉字 width += 2; } else if (c >= '\uFE10' && c <= '\uFE19') { // 竖排形式 width += 2; } else if (c >= '\uFE30' && c <= '\uFE6F') { // CJK 兼容形式 width += 2; } else if (c >= '\uFF00' && c <= '\uFF60') { // 全角形式 width += 2; } else if (c >= '\uFFE0' && c <= '\uFFE6') { // 全角符号 width += 2; } else { width += 1; } } return width; } public static boolean isValidTitle(String title) { if (title == null || title.isEmpty()) { return false; } // 假设标题允许 40 个字符宽度 return getDisplayWidth(title) <= 40; } }

这里有一点要提醒：Java 的char是 UTF-16 编码，直接遍历charAt可能会把 emoji 拆成两个char。如果业务里允许 emoji，建议用codePointAt配合Character.charCount遍历，或者直接使用ICU4J的UCharacter.getIntPropertyValue获取 East Asian Width 属性。上面示例只是为了说明思路，生产环境中建议接入成熟库，避免重复造轮子。

6. 等宽字体、Canvas 和终端的字符宽度测量

字符宽度在浏览器布局里可以通过 CSS 隐式控制，但如果你想精准地测量一段文字到底多宽，必须走到字体渲染层。常见的测量方式有两种：Canvas 的measureText和终端库的wcwidth。

6.1 用 Canvas 测量真实像素宽度

浏览器里最可靠的测量方式之一，是创建一块离屏 Canvas，设置好字体样式，然后用measureText方法获取文本宽度。

// 文件路径：utils/canvasTextWidth.js /** * 测量文本在指定字体样式下的像素宽度 * @param {string} text * @param {string} fontStyle CSS font 简写属性，例如 '14px "Microsoft YaHei"' * @returns {number} */ function measureTextWidth(text, fontStyle = '14px sans-serif') { const canvas = document.createElement('canvas'); const ctx = canvas.getContext('2d'); ctx.font = fontStyle; const metrics = ctx.measureText(text); return metrics.width; } // 示例用法 const titleWidth = measureTextWidth('你好 CSDN', '16px "PingFang SC", sans-serif'); console.log(titleWidth); // 输出像素宽度

measureText返回的width是文本在指定字体下的实际渲染宽度，单位是像素。这个方法可以用来做“按真实像素截断”的工具，比如多行文本超过容器宽度时，二分查找最适合截断的位置。缺点是需要先知道最终渲染的字体和字号，如果页面字体加载前后不一致，结果也会变化。

6.2 终端表格对齐中的字符宽度问题

在终端里写日志或 CLI 工具时，我们经常用空格补齐列宽。问题在于，中文字符在终端里的显示宽度通常是英文字符的两倍，如果按字符个数补空格，中文列会错位。

# 文件路径：examples/terminal_align_bad.py def print_bad_table(rows): for row in rows: line = "" for cell in row: line += cell.ljust(20) print(line)

假设有一行单元格是"姓名"，一行是"Bob"，由于"姓名"的实际显示占 4 个英文字符宽度，ljust(20)会补 16 个空格，而"Bob"只占 3 个宽度，会补 17 个空格。这个差异累积之后，列就完全对不齐了。

正确的做法是用wcwidth库计算显示宽度，再用差值补空格。

# 文件路径：examples/terminal_align_good.py try: from wcwidth import wcswidth except ImportError: raise SystemExit("请先安装 wcwidth: pip install wcwidth") def pad_by_width(text, width, align="left"): """ 按终端显示宽度对齐字符串 :param text: 原始字符串 :param width: 需要的终端显示宽度 :param align: left / right """ diff = width - wcswidth(text) if diff <= 0: return text if align == "left": return text + " " * diff return " " * diff + text def print_good_table(header, rows): col_widths = [wcswidth(h) for h in header] for row in rows: for i, cell in enumerate(row): col_widths[i] = max(col_widths[i], wcswidth(cell)) header_line = " ".join(pad_by_width(h, col_widths[i]) for i, h in enumerate(header)) print(header_line) print("-" * wcswidth(header_line)) for row in rows: print(" ".join(pad_by_width(cell, col_widths[i]) for i, cell in enumerate(row))) if __name__ == "__main__": headers = ["姓名", "Score", "备注"] data = [ ["张三", 96, "优秀"], ["Bob", 88, "Good"], ["王小明", 100, "Excellent"], ] print_good_table(headers, data)

在 Python 生态里，wcwidth是对 Unicode 标准中 East Asian Width 属性的一个实现，它知道哪些字符在终端里占 2 列、哪些占 1 列。对于中文、日文、韩文和全角符号，它都能给出正确结果。

6.3 为什么不要自己数 Unicode 范围

网上很多人分享过“判断全角字符的正则”，大方向没错，但 Unicode 字符太多，维护成本很高。比如：

• 某些特殊符号在不同终端和字体下宽度不同；
• emoji 的宽度还受终端和平台的渲染策略影响；
• 组合字符（字母加音标）显示时可能只占一个位置，但逻辑上是多个码点。

所以，如果项目里经常需要处理终端对齐、CLI 表格、富文本排版，优先使用成熟的字符宽度库：

• Python：wcwidth
• Node.js：string-width
• Java：ICU4J的UCharacter+UTF16

7. 常见问题与排查思路

8. 最佳实践与工程建议

结合多个项目的实战经验，这里给出几条关于字符宽度设置的建议，按照重要性排列。

8.1 明确业务需求的“宽度”到底是哪一层

接到需求时，先确认产品说的“宽度”是指：

• 视觉宽度（用户看到的长度）？
• 字符个数（逻辑上的长度）？
• 存储字节（数据库容量）？

同一个字段，在这三个维度里的限制条件可能分别都要设置。比如标题：

• 前端按视觉宽度限制，避免界面溢出；
• 后端按字符数做最终校验，防止恶意构造超长字符串；
• 数据库按字符数或字节数定义字段长度，保证能存储。

三个维度不是一回事，不能只做一个。

8.2 尽量复用成熟库，不要手写全角正则

尽管我在文章里给出了简易正则，但在生产环境中，我个人更推荐使用更完整的实现：

• 前端：string-width、@formatjs/intl相关工具。
• Python：wcwidth。
• Java：ICU4J。

这些库考虑了 East Asian Width 属性、组合字符、emoji 等边界情况，比自己维护正则可靠得多。

8.3 做截断时，优先在 UI 层做，而不是在数据层做

如果只是“展示时太长”，应该在展示层做 CSS 截断或脱敏，而不是直接把原始数据截断存进数据库。因为不同端、不同字体、不同设备需要的截断宽度不一样。把原始数据保持完整，交给各端自行适配，是更灵活的方案。

8.4 数据库统一使用 utf8mb4，字段长度按字符数设计

新项目建表时，尽量使用utf8mb4，不要再用utf8，否则 emoji 和生僻字没法存。字段长度按业务允许的字符数来定义，例如最多 20 个汉字，就定义VARCHAR(20)。如果同一个字段可能存各种字符，且前端已经按视觉宽度限定了输入，那么VARCHAR(50)通常够用，但不要盲目照搬。

如果字段要存大量富文本，不要用VARCHAR硬撑，直接用TEXT或MEDIUMTEXT更合适。

8.5 做好字符宽度与可访问性的平衡

固定宽度截断长文本时，要给可访问性留余地。屏幕阅读器用户看到的不是视觉宽度，而是完整内容。如果只靠text-overflow: ellipsis截断，视觉上没问题，但读屏软件可能只读到省略号前的文字。更稳妥的做法是：

• 在 HTML 里保留完整文本；
• 用 CSS 做单行或多行省略；
• 需要时可设置title属性或提供展开按钮。

8.6 字体加载前后，测量结果会变化

通过measureText或自定义字体做截断时，如果页面使用了@font-face异步加载的字体，第一次测量和字体加载完成后的测量结果可能不同。建议在document.fonts.ready之后再执行截断类逻辑。

document.fonts.ready.then(() => { const width = measureTextWidth('你好 CSDN', '16px "PingFang SC", sans-serif'); console.log(width); });

8.7 不追求像素级一致，而是追求业务可接受

有人希望“所有设备、所有浏览器下，20 个汉字必须显示成完全一样的像素宽度”。在 Web 环境里，这几乎不可能，因为字体渲染、设备像素比、浏览器缩放都会影响最终尺寸。更务实的目标是：

• 不用length做宽度判断；
• 对超长内容有兜底策略（省略号、换行、横向滚动）；
• 关键布局不因文本长度差异被破坏。

8.8 在日志和监控中增加异常追踪

如果字符宽度问题频繁出现，建议在接口层增加异常追踪。比如后端校验到长度异常时，记录输入字符串的长度、字符集、调用方信息，方便定位是哪个客户端、哪种内容触发的。

9. 总结与后续学习方向

这篇文章从问题出发，把字符宽度的几个主要应用场景串了一遍：

• 如何理解“字符个数、字节长度、视觉宽度”三个概念的区别；
• 前端用 CSS 控制文本宽度的典型方式和边界；
• 中英文混排时如何按显示宽度做输入校验；
• 数据库字段长度设计时要注意的字符集与长度单位；
• 终端和 Canvas 中的真实字符宽度测量方法。

建议下一步动手验证几个事情：

1. 打开 DevTools 的 Console，用measureText分别测量中英文混合字符串在不同字体下的像素宽度，感受字号与字体的影响。
2. 在你正在做的表单项目里，把maxlength从“字符数限制”改成“宽度限制”，对比产品体验差异。
3. 在终端写一个打印表格的小工具，使用wcwidth做对齐，理解为什么补空格不能解决问题。
4. 查看当前数据库表的字符集和字段长度，执行CHAR_LENGTH(title)与LENGTH(title)，确认现有数据有没有潜在的截断风险。

字符宽度问题看似细小，但它在表单校验、布局、日志、数据存储各个层面都会冒出来。提前把概念和工具链理顺，能省下大量排查时间。希望这篇文章对你有用，也欢迎在评论区聊聊你在中英文混排和宽度计算上踩过的坑。