企业官网建设流程全解析

做报表的同学大概都有过这种体验：业务方甩过来一句“日期麻烦统一成 2024-03-15 这种”，结果你打开表一看，那一列存的是datetime，另一张表存的是字符串'15/03/2024'，还有一张表干脆把年月日拆成了三列。这时候大多数人第一反应是去应用层写代码循环处理，但只要数据量一上去，几十万行拉出来再格式化，光网络往返就够喝一壶。真正省事的做法是在查询里直接解决，而 SQL 里的CONVERT 转换函数就是干这个的——它负责在数据类型之间搭桥，尤其是把日期、数值转成各种形状的字符串，或者反过来。这篇内容我会围绕 CONVERT 的实际用法展开，从语法细节、style 编码表，到日期和数值两块最容易翻车的地方，以及几个我自己踩过的坑。适合已经会写基本 SQL、但每次遇到格式转换都要去搜索引擎翻一遍编码表的开发者看，也适合刚接触数据库、想把类型转换这件事一次性搞明白的新人。

1. CONVERT 在日常开发里到底干了什么活

1.1 一条报错带出来的真实场景

前段时间帮一个朋友排查问题，他那边有个对账查询，跑出来报错说“从字符串转换日期和/或时间时，转换失败”。这句提示很多人见过，但真正难的不是报错本身，是它没告诉你到底是哪一行、哪个值出的问题。翻了半天发现，那张对账表的日期字段是varchar(20)，绝大多数值长这样'2024-01-08'，但有几条是运营手工补录的'2024/1/8'，还有一条是从老系统迁过来的'20240108'。三种格式混在一列里，数据库在解析时只能按当前的语言和日期格式设置去猜，猜不中就整体报错。

这个场景基本概括了 CONVERT 的两大主战场：一是把日期时间类型转成指定格式的字符串，比如报表导出、接口返回、文件命名；二是把字符串按指定格式解析成日期或数值，比如从外部导入的文本数据入库。它和 CAST 功能上有重叠，但 CONVERT 多出来的那个 style 参数，才是它在实际项目里被反复使用的原因。理解了这层，后面所有的编码表、格式串就不是死记硬背，而是“我要什么输出，就查对应编码”。

值得一提的是，CONVERT 并不负责“清洗数据”。它不会帮你把'2024/1/8'自动识别成合法日期再去匹配另一种格式，它只在解析失败时直接抛错（或者用 TRY_CONVERT 返回 NULL）。所以任何涉及外部数据导入的流程，转换之前必须先做格式摸底，这一步谁也省不掉。

1.2 CONVERT 与 CAST 的分工边界

很多人问，既然有 CAST，为什么还要用 CONVERT。这两个的关系其实很简单：CAST 是标准写法，语法是CAST(expression AS data_type)，可移植性好；CONVERT 是带额外能力的写法，语法是CONVERT(data_type, expression, style)，多一个 style。功能上 CAST 能做的 CONVERT 都能做，反过来不成立——凡是需要控制输出格式的场合，CAST 就无能为力了。

举个具体例子。要把当前时间转成yyyy-mm-dd这种形式，写CAST(GETDATE() AS varchar(10))得到的大概率是'Jan 8 2024'这种带月份英文缩写的形态，因为 CAST 转字符时走的是默认格式。而CONVERT(varchar(10), GETDATE(), 23)得到的才是干干净净的'2024-01-08'。差别就在这一个数字上。

我的选型习惯是这样的：如果只是类型层面的转换，比如把int转bigint、把varchar转nvarchar，一律用 CAST，语义清晰、跨库迁移时不用改；只要涉及“转成字符串并且对结果长相有要求”，或者“从字符串解析成日期/数值并且要指定解释方式”，就直接上 CONVERT。团队里最好把这条规则写进规范，否则同一个项目里两种写法混着用，后面接手的人会很难受。另外还有一个现实因素：某些数据库产品对 CONVERT 的支持形式不完全一样，如果真的要考虑跨库，格式化的活尽量放到应用层，这一点我在第 6 节会展开说。

1.3 style 参数：CONVERT 真正值钱的地方

style 是一个整数，看着不起眼，但它决定了输出长什么样。它的取值不是随便编的，而是有一套历史沿革的编码体系：0 到 14 是早期的一批，100 到 114 是在对应的老编码上加 100 得到的“带世纪”版本，120 以上则是后来补充的 ISO 风格格式。比如 1 表示mm/dd/yy，101 表示mm/dd/yyyy，区别就是年份是否四位。

这套编码最坑的地方在于，它不是所有类型都生效。style 主要作用于三类转换：日期时间类型到字符、字符到日期时间类型、以及 float/real/money 到字符。如果你把一个decimal转成varchar并带上 style，实测下来那个 style 基本被忽略，输出就是普通数字，想加千分位分隔符还是得自己拼字符串。同理，把int转varchar时写 style 也没意义。搞清楚适用范围，能省掉很多“为什么我写了 style 没反应”的困惑。

还有一点值得提醒：style 只影响“字符串的表现形式”，不影响底层存储。你用 CONVERT 转出来的'2024-01-08'本质上还是一个字符串，它不能参与日期加减，也不能用日期函数。如果后续还要做时间计算，就别急着转成字符，把转换放到最外层、最后一步再做。

2. 三个参数的写法拆解与常见误用

2.1 目标类型括号里的长度，是最容易漏的地方

CONVERT 的第一个参数是目标类型，完整写法是data_type(length)。这个长度在很多示例代码里被省略了，因为省略时有默认值——转varchar不写长度默认是 30。默认值这东西平时不显眼，一旦输出超长就会出事。

我遇到过最典型的一次：某个导出功能要把订单备注（nvarchar(500)）转成varchar拼进一个用竖线分隔的字符串里做日志。代码写的是CONVERT(varchar, Remark)，测试环境数据短，一切正常；上了生产，几条长备注直接被砍到 30 个字符，日志里全是截断的残句，排查问题时反而误导了方向。这种错误不会报异常，属于典型的静默截断，只能靠代码审查和边界数据测试发现。

所以我的习惯是：只要目标是变长字符类型，长度一律显式写出来，而且要按源字段的最大可能长度来估。源是nvarchar(200)，目标就写varchar(400)，因为中文在非 Unicode 字符类型下可能占多个字节，留出余量比事后补救便宜得多。另外，如果目标类型是nvarchar，长度单位是字符数，一个汉字算一个；如果是varchar，那就要看排序规则和编码方式了，这个差异在混用两种类型时特别容易出问题。

2.2 源表达式：看起来是数字的字符串不一定是数字

第二个参数是源表达式，可以是一列、一个常量、一个函数结果，甚至是带运算的表达式。这里最容易踩的坑不是语法，而是对源数据质量的误判。

举个很常见的例子：某张表里手机号存在varchar(20)字段里，现在要转成bigint做去重统计。写CONVERT(bigint, Phone)语法完全正确，但只要有一条记录的 Phone 是空字符串''，或者带了个+86前缀，整个查询就直接报转换失败。更麻烦的是如果这列允许 NULL，NULL 转数字是没问题的（结果还是 NULL），所以你会看到“有些行可以有些行不行”的诡异现象。

判断一列能不能安全转换，别靠肉眼看前一百行。稳妥的做法是先跑一个筛查查询，把所有“看起来不该出现”的值捞出来。比如：

SELECT Phone FROM Customer WHERE Phone IS NOT NULL AND (LTRIM(RTRIM(Phone)) = '' OR Phone LIKE '%[^0-9]%');

这个LIKE '%[^0-9]%'的写法能一次性把所有含非数字字符的值筛出来，比ISNUMERIC()靠谱——ISNUMERIC对'1e5'、'$100'、'1,000'这些都返回 1，但它们在转int时会失败，属于历史遗留的坑。筛查干净之后再转，成功率会高很多。

2.3 style 编码速查与填错后的后果

style 填错的后果分两种。如果填了一个不存在的编码，比如 99，数据库通常会忽略它、走默认格式，不会报错，于是你会得到一个“看起来能用但格式不对”的结果，这种最难发现。如果填了一个存在于别的类型体系里的编码，比如给日期转字符填了 2（在数值体系里 2 表示保留四位小数），结果依然按日期的编码解释，得到yy.mm.dd。

下面这张表是我自己常用的日期格式速查，按输出形态分组，比按数字顺序背要好记很多：

填的时候有个小技巧：带世纪的四位年版本，编码基本等于老编码加 100。1 对应 101，2 对应 102，3 对应 103，依此类推一直到 114 对应 14。记住这个规律，遇到不常用的编码就不用现查了。但要注意 120、121、126 这几个是后来新增的，不遵循加 100 的规则，得单独记。

3. 日期与时间转换：用得最多也最容易出事的一块

3.1 日期转字符：按下游要什么格式就写什么 style

日期转字符这个方向相对安全，因为源是标准类型，不存在解析失败的问题，唯一要操心的是输出格式和长度。真正需要留意的是目标长度和 style 的匹配。

CONVERT(varchar(10), GETDATE(), 120)是个流传很广的写法，意图是“只取日期部分”。它确实能work，因为 120 的输出是yyyy-mm-dd hh:mi:ss，截到 10 位正好是日期。但这本质上是个取巧——依赖的是截断行为，而不是语义。如果有人后来把长度改成 19，结果就变成完整时间；改成 16，就变成yyyy-mm-dd hh:m，看着像时间其实少了秒。这种写法在代码评审时很容易被放过去，但它是脆弱的。

更明确的写法是两个：要纯日期就用CONVERT(date, GETDATE())（结果是 date 类型，不是字符串）或者CONVERT(varchar(10), GETDATE(), 23)；要完整时间就用 120 配上varchar(19)。长度和 style 的输出长度对齐，看代码的人一眼就知道意图。

还有一个细节值得说：如果你要的输出里有中文，比如2024年01月08日，没有哪个 style 能直接生成，必须自己拼：

SELECT CONVERT(varchar(4), YEAR(GETDATE())) + '年' + RIGHT('0' + CONVERT(varchar(2), MONTH(GETDATE())), 2) + '月' + RIGHT('0' + CONVERT(varchar(2), DAY(GETDATE())), 2) + '日';

那个RIGHT('0' + ..., 2)是补零的标准套路，比FORMAT函数快得多——FORMAT内部走 CLR，几万行数据上差距非常明显，我在百万级的导出任务里实测过，用 FORMAT 整条语句跑了两分多，换成字符串拼接直接降到十几秒。

3.2 字符转日期的格式不确定性

反方向才是真正的雷区。字符串转日期时，数据库需要知道“这个字符串该怎么理解”，而这个理解方式受两个会话设置影响：SET DATEFORMAT和SET LANGUAGE。

最典型的歧义是'01/02/2024'。按北美习惯它是 1 月 2 日，按欧洲习惯它是 2 月 1 日。如果你不加 style 直接CONVERT(date, '01/02/2024')，结果取决于当前会话的 DATEFORMAT 设置。同一段代码在不同服务器上跑出不同结果，这种 bug 查找起来极其痛苦，因为你本地永远复现不了。

解决办法是永远显式指定 style。你明确知道源字符串是yyyy-mm-dd，就写CONVERT(date, Col, 23)；是yyyymmdd，就写 112。这样解析规则就固定下来了，不受会话设置影响。我个人的经验是，凡是字符串转日期的场合，没有例外，全都带上 style，宁可多打两个字符。

另一个高频问题是格式不统一。前面提到的'2024-01-08'、'2024/1/8'、'20240108'混在一列，没有任何一个 style 能通吃。这时候的处理思路是分段转换：先用正则或 LIKE 把数据按形态分类，每类用对应的 style，剩下的转不了的单独捞出来人工处理。虽然麻烦，但比一次性整体报错要可控得多。如果数据库版本支持，用TRY_CONVERT会更省事：

SELECT RawDate, COALESCE( TRY_CONVERT(date, RawDate, 23), TRY_CONVERT(date, RawDate, 111), TRY_CONVERT(date, RawDate, 112) ) AS ParsedDate FROM ImportTable;

这段逻辑的意思是“按三种格式依次尝试，哪个成功用哪个”，失败的返回 NULL 而不是中断整个查询。对于一次性导入任务，这是最实用的写法。

3.3 只取日期或只取时间的写法与性能

“我只想要日期，不想要时间”这个需求在报表里太常见了。实现方式有好几种，性能差别不小。

第一种是CONVERT(varchar(10), Col, 23)，转成字符串。优点是输出干净、前端直接可用；缺点是它是字符串，后续没法做日期比较和计算。

第二种是CONVERT(date, Col)，转成 date 类型。这是 2008 之后版本的标准做法，语义最清晰，类型也对。但如果这一列上有索引，写在 WHERE 条件里就要小心了，因为对列做函数包装会导致索引失效——这一点在第 5 节详细说。

第三种是老写法DATEADD(DAY, DATEDIFF(DAY, 0, Col), 0)，把时间部分抹掉但同时保持 datetime 类型。这种写法在需要保留 datetime 类型又要抹零的场合仍然有用，而且它是可索引的（因为右侧是常量表达式）。

三者的取舍很简单：只用于展示、不做后续计算的，用第一种；要参与比较的，用第二种，但记得别把它包在 WHERE 的列上；需要保留 datetime 语义又要抹零的，用第三种。我在实际项目里见过有人在 GROUP BY 里写CONVERT(varchar(10), Col, 23)做按天汇总，如果数据量大，改成CONVERT(date, Col)会好一些，虽然还是有函数调用，但至少类型转换比字符串处理开销小。

4. 数值、金额与字符之间的转与舍

4.1 decimal、float、money 转字符时的 style 差异

数值转字符这块，style 的适用范围比日期窄得多，但坑一点不少。

先说float和real。这两个类型转字符时，style 有三个有效值：0 表示最多保留 6 位小数、不用科学计数法；1 表示用科学计数法、 mantissa 部分带 8 位；2 表示最多保留 16 位、不用科学计数法。实际写代码时，0 是最常用的。但要注意 float 本身是近似类型，0.1 + 0.2这种运算的结果可能带一长串尾数，转成字符会原样吐出来，看着很不体面。真要展示金额，从一开始就不该用 float。

再说money和smallmoney。这两个类型转字符时，style 0 表示不带千分位、两位小数；1 表示带千分位、两位小数；2 表示不带千分位、四位小数；3 表示带千分位、四位小数。这里有个隐藏依赖：千分位符号和货币符号受会话的语言设置影响。在某些语言环境下，千分位可能是空格或者点号，输出会跟预期不一样。所以凡是给外部系统输出的场景，我一般不用 money 的 style，而是自己控制格式：

SELECT REPLACE(CONVERT(varchar(20), CONVERT(decimal(18,2), Amount)), ',', '')

先把金额规整成两位小数的 decimal，再转字符，最后按需要处理分隔符。这样输出完全可控，不受会话设置干扰。

最后说decimal和numeric。前面提过，这俩转字符时 style 基本不起作用，输出就是普通的数字串。想要千分位得自己拼，或者用FORMAT（性能代价前面说过了）。如果是整数类型，CONVERT(varchar(10), 12345)得到'12345'，没什么可调的。

4.2 转换失败怎么定位：先筛出脏数据再转

字符串转数值的失败率比转日期还高，因为数值的合法形式判断更严格。只要有一个字符不对，整条语句就崩。

定位思路是“二分法+筛查”。先跑一个总数统计，确认有多少行；再跑一个“能成功转换的行数”，两者相减就知道有多少脏数据；然后按可能的脏数据特征逐类筛查。实用的筛查条件有这么几条：

-- 空字符串或纯空格 WHERE LTRIM(RTRIM(Col)) = '' -- 含非数字字符（允许负号和小数点） WHERE Col LIKE '%[^0-9.-]%' -- 有多个小数点 WHERE LEN(Col) - LEN(REPLACE(Col, '.', '')) > 1 -- 负号不在首位 WHERE CHARINDEX('-', Col) > 1

这几条筛下来，基本能把 99% 的问题数据定位到。剩下转不了的，八成是超长数字（比如 20 位的订单号转 int）或者科学计数法表示。

这里再强调一次ISNUMERIC的问题：它对'1e5'返回 1，因为科学计数法是合法数值；对'$100'也返回 1，因为货币符号在某些语境下被接受；对','甚至也返回 1。所以拿它当“能不能转 int”的判断依据是不可靠的。要用就用TRY_CONVERT(int, Col) IS NULL，直接试一次真转换，结果为 NULL 的就是转不了的，比ISNUMERIC准确得多。

4.3 隐式转换这个比 CONVERT 本身更大的问题

聊显式转换的时候，绕不开隐式转换，因为它造成的问题往往更隐蔽。

所谓隐式转换，就是你没写 CONVERT，但数据库在比较或运算时自动做了类型转换。比如WHERE VarcharCol = 123，左边是字符右边是数字，数据库会把字符列转成数字再比。当转换发生在列上时，索引就用不上了，只能全表扫描。而且如果列里有非数字内容，这个查询还会直接报错——一个“查询”语句因为数据脏而报错，很多人第一次遇到会觉得莫名其妙。

类型优先级也值得记一下：数值类型优先级高于字符类型，所以字符和数字比较时，字符会被转成数字。日期和字符比较时，字符会被尝试解析成日期。nvarchar和varchar比较时，varchar会被转成nvarchar。这些规则本身不难，但组合起来就复杂了。

我的原则很简单：WHERE 条件两边的类型必须一致。应用层传参进来是字符串，那就把它显式转成对应类型再传，别指望数据库帮你兜。这既是性能考虑，也是可维护性考虑——显式转换写在明面上，后面的人一看就懂；隐式转换藏在类型系统里，出问题时很难一眼看出来。

5. 四个真实踩坑的排查链路

5.1 长度写小了，值被静默截断

这个问题前面提过一次，但值得展开讲讲排查过程，因为它太隐蔽了。

现象是：某个查询返回的结果里，本该是完整地址的字段只剩前半截，且没有任何报错。第一反应是前端截断了？查了前端代码，没截。是不是字段本身存的时候就短？直接 SELECT 原字段，是完整的。那问题只能出在中间的转换环节。

顺着语句往回看，发现有这么一段：CONVERT(varchar(50), Address)。而 Address 是nvarchar(100)，最长的值有 80 多个字符。原因一下就清楚了：转成varchar(50)时，超过 50 的部分被直接丢弃，不报错、不警告。

修法很直接，长度改成 100 或者干脆不指定（默认 30 更小，反而更坑）——不对，正确做法是显式写一个足够大的长度，varchar(200)之类的。这个坑的教训是：任何长度不放心的转换，先跑一次MAX(LEN(Col))看看实际最大长度，比拍脑袋定数字靠谱。

顺带说一个相关的：如果目标类型是char而不是varchar，长度不够时同样是截断，够长时又会补空格，输出里会莫名其妙多出尾随空格，比较的时候'abc '和'abc'在某些排序规则下不相等，这种问题排查起来更绕。所以除非有明确理由，字符类型一律用varchar/nvarchar。

5.2 日期字符串和语言设置打架

现象：同一段转换代码，在测试库上正常，上了另一个环境的库就报错或者结果错一天。

这类问题的排查链路比较固定。第一步确认源字符串的实际格式，从数据里捞出几条样本；第二步确认目标环境的DATEFORMAT和LANGUAGE设置，用DBCC USEROPTIONS可以看当前会话的设置；第三步检查代码里有没有显式 style，没有的话就基本锁定原因了。

我遇到过最典型的一次是新旧两套环境语言设置不同，一个默认us_english，一个默认British。源数据是'03/04/2024'，在两个环境里分别被解析成 3 月 4 日和 4 月 3 日，报表数字对不上，业务方找了两天才找到我们这边。修复方式就是给所有字符转日期的地方补上 style，一行代码的事，但没有这个意识的话，问题会一直潜伏。

这个坑的通用教训是：凡是跨环境的代码，不能依赖会话默认设置。语言、日期格式、排序规则，这三样都要显式对待。

5.3 在 WHERE 条件里套 CONVERT，索引直接失效

这个问题的现象是：查询逻辑完全正确，结果也对，就是慢，慢到超时。

排查方式看执行计划。如果看到一个本应走索引查找的查询变成了全表扫描，而且扫描的对象上确实有索引，那就往“列被函数包裹”这个方向想。WHERE CONVERT(date, OrderDate) = '2024-01-08'就是典型——因为要对每一行先算出日期再比较，优化器没法用索引。

改法是把函数从列上挪到常量上，或者改写成范围查询：

-- 慢：列上套函数 WHERE CONVERT(date, OrderDate) = '2024-01-08' -- 快：范围查询，索引可用 WHERE OrderDate >= '2024-01-08' AND OrderDate < '2024-01-09'

第二种写法看起来啰嗦，但它让OrderDate保持“裸露”状态，索引能正常用上。如果你觉得每次手写边界太麻烦，可以先算出当天的起止时间存成变量再传进来。

这个坑值得单独拎出来说，因为它的隐蔽性在于结果正确。结果对的查询没人会去怀疑，直到数据量涨上来才发现问题。

5.4 TRY_CONVERT 在低兼容级别下不可用

TRY_CONVERT是解决转换失败的利器，但它不是所有环境都能用。它要求数据库兼容级别在 110 以上。如果某个老库还停留在较低的兼容级别，写TRY_CONVERT会直接报“对象名无效”——注意这个报错说的是“对象名”，很容易让人以为是表名写错了，往错误方向排查。

遇到这个报错，先做两件事：查兼容级别，SELECT compatibility_level FROM sys.databases WHERE name = DB_NAME()；确认版本支持。如果兼容级别确实低，要么提级别（需要评估影响），要么改用CASE WHEN加ISNUMERIC之类的替代方案，虽然不完美但至少能跑。

这也提醒了一件事：写涉及新函数的代码之前，先确认目标环境的最低版本。团队里如果有多个环境的版本参差不齐，最好在规范里写清楚“哪些函数可以用，哪些不能用”，比每个人各自踩坑要高效。

6. 让转换代码不脏的几条工程习惯

6.1 格式化的活到底该落库还是落应用层

这是个经常争论的问题。我的观点是分场景，判断标准有两条：数据量和耦合度。

如果只是单条记录的详情页展示，把datetime原样传出去，让应用层去格式化，这个方案最灵活，改格式不用动 SQL。如果是几十万行的报表导出，在数据库里转好再传，能省掉大量对象创建和序列化开销，性能优势明显。如果是给外部系统提供的接口，那就要看对方能不能接受多一种类型——如果能，传原始类型最省事；如果不能，在出口处统一转一次，别在每个查询里各转各的。

最忌讳的是混着来：同一个字段，A 接口在库里转好，B 接口在应用层转，两边的格式还不一致。这种不一致迟早会引发下游的显示问题。我的建议是在项目初期就定一条线，比如“所有对外输出的日期一律yyyy-mm-dd HH:mm:ss，在数据访问层统一处理”，然后把这条规则落到一个公共方法里。

6.2 统一封装一个格式化函数

如果确实需要在 SQL 里做格式化，别在几十个地方散着写 CONVERT，抽一个标量函数出来。虽然标量函数有性能开销（逐行调用），但在数据量不算极端、复用度高的场景下，可维护性的收益远大于那点开销。

CREATE FUNCTION dbo.fn_FormatDate ( @dt datetime, @style varchar(20) ) RETURNS varchar(30) AS BEGIN DECLARE @r varchar(30); SET @r = CASE @style WHEN 'date' THEN CONVERT(varchar(10), @dt, 23) WHEN 'time' THEN CONVERT(varchar(8), @dt, 108) WHEN 'full' THEN CONVERT(varchar(19), @dt, 120) WHEN 'short' THEN CONVERT(varchar(10), @dt, 112) ELSE CONVERT(varchar(19), @dt, 120) END; RETURN @r; END;

这个函数的价值在于把“格式定义”集中到了一处。哪天业务方说日期要改成斜杠分隔，只改一个 CASE 分支就行，不用全项目搜索CONVERT。而且它顺带解决了长度问题——返回值统一是varchar(30)，不用每个调用点各自估算。

要注意的是，如果是在大表查询的 SELECT 列表里用这个函数，性能会受影响。折中方案是只在小结果集（比如导出、详情页）里用，大表聚合场景还是内联写 CONVERT。

6.3 上线前值得跑一遍的自测清单

写转换相关的代码，我一般会过一遍下面这几条，能把大部分低级问题挡在上线前：

这张表看着简单，但每一条都对应过我或者同事踩过的真实坑。尤其是第一条和第三条，属于“不做不一定出事，做了能省半天”的类型。

另外补一个小技巧：测试转换逻辑的时候，别只用正常数据测。专门造几条极端数据——最长字符串、空串、NULL、全角数字、带前导空格的值，一起塞进去跑一遍。这些边界值才是真正能暴露问题的地方，正常数据永远测不出截断和解析歧义。

最后分享一个我在实际项目中体会最深的点：CONVERT 这类函数的语法本身五分钟就能学会，真正花时间的是对数据本身的理解。同一列数据里到底藏着多少种格式、有没有全角半角混用、有没有不可见字符，这些才是决定转换代码能不能一次跑通的关键。我现在接手任何涉及数据转换的需求，第一步都不是写 SQL，而是先花十分钟把源数据摸一遍，把各种异常样本捞出来看看——这十分钟往往能省掉后面两个小时的排查。转换函数是工具，数据质量才是根本，工具用得再熟练，源数据不摸底，该翻车还是翻车。