带过几个MATLAB项目之后我发现一个有趣的现象刚接触文本处理的人几乎都会被单引号和双引号的区别搞晕一次。hello 在 MATLAB 里是 1×5 的 char 数组而 hello 是 1×1 的 string 对象前者 ischar 返回 1后者 isstring 返回 1。同一串字符索引、拼接、比较的规则却完全不一样代码里混用起来非常容易踩坑。这篇内容就围绕 MATLAB 中 char 和 string 这两套文本体系展开把它们的底层逻辑、行为差异、转换方法、迁移经验一次讲清楚适合刚开始用 MATLAB 写文本处理脚本的新人也适合维护着一堆老代码、想把部分逻辑迁到新 API 的开发者。1. 两套体系的由来从一切皆矩阵到独立字符串对象1.1 char 的本质是字符数组不是字符串在 MATLAB 的初始世界观里一切数据都是矩阵char 就是这种哲学的直接产物。单引号 hello 创建的是一个 1×5 的 char 行向量每个元素是单个字符。类型名是 char但它和 C/C 里那个 char 完全不是一回事它天然具备数组的全部属性。你可以把它当普通矩阵来操作hello(1) 取第一个字符 hhello(1:3) 取出 heldouble(A) 可以得到 65char(65) 又能变回 A。这些行为说明 char 与数值矩阵用的是同一套底层模型每个字符本质上就是 Unicode 码元在内存里按 UTF-16 编码占两个字节。正因为 char 是数组它才有一堆数组的病。比如用 [abc; def] 能建一个 2×3 字符矩阵但如果两行长度不一样写成 [abc; de]MATLAB 直接报错你必须手动补空格让每行等长。这种处理方式对写惯 Fortran 和 C 固定长度字符数组的老程序员来说很熟悉但对新用户就非常反直觉。1.2 string 是 R2016b 才有的亲儿子由于 char 的数组语义在文本处理上太别扭MathWorks 在 R2016b 引入了真正的 string 类型。双引号 hello 创建的是一个 1×1 的字符串数组标量它每个元素都是一个完整的字符串对象可以包含任意长度包括 0 个字符的文本。string 的形态和 char 有本质区别它看起来也是数组但元素不是字符而是字符串。[apple, banana] 是 1×2 的字符串数组两个元素分别是 apple 和 banana。它和 C 的 std::string、Java 的 String 有点像但更接近一个字符串的向量容器。通俗理解char 是按字符排列的多维数组string 是按文本条目收纳的容器。string 还引入了missing这个显式缺失值标记空字符串用表示。这两件事在 char 的世界里都只能用空数组将就语义不够清晰。这些设计明显是在为表格数据、文本分析和现代 API 铺路。1.3 都发展这么多年了为什么还是两套并存按常理有了新类型旧类型就该退居二线。但 MATLAB 不可能这么做几十年积累的历史代码、工具箱内部实现、MEX 接口、Simulink 模块参数全部建立在 char 之上。官方如果强行抛弃整个生态就得重构这是不现实的。所以现实就是官方文档推荐优先使用 string但几乎所有底层工具箱对 char 的支持依然稳固而且很多函数的默认行为就是产生 char。fprintf 的格式控制、文件读取函数 fgetl、老式 GUI 回调参数传递这些场景到现在依然输出 char。我们做项目时没法只选其一必须两套都掌握并且随时注意边界上的兼容性。这也是我写这篇文章的直接动机。2. 操作行为差异同一个操作结果可能完全不一样2.1 索引与修改string 取首字符不是 s(1)这是新手最常踩的坑。对 char 数组s MATLABs(1)返回 Ms(4)返回 L把s(1) m还能直接改数组里的字符这就是数组的常规用法。对 string 数组就不一样了。s MATLABs(1)返回的是整个字符串 MATLAB不是首字符。想要首字符你得先char(s)再索引或者用 extractBefore、extractBetween 这类文本提取函数。而且 string 元素本身是不可变的你没法像改 char 数组那样原地改某一位字符想修改就得用 replace、extractBefore 等函数生成新字符串再赋值回去。这个差异不是小事在高频循环里把 string 当 char 索引轻则逻辑错误重则数组维度直接爆炸。举一个我见过的真实错误。有人遍历文件名数组时写了files [a.log, b.log, c.log]; for i 1:numel(files) prefix files(i, 1); % 本意是想取第一个字符 a end结果 prefix 一直等于整个文件名后面所有比较全部错乱。如果 files 是 char 矩阵或 cellstrfiles(i,1)才真的是取出第 i 行第一列字符。这个例子我讲给过不少同事大家几乎都中过招。2.2 拼接[] 和 对两套体系是两种玩法文本拼接是日常刚需但这里的坑最多。对 char 数组[]是水平拼接[ab, cd]和[ab cd]等价直接得到 abcd。对 string 数组[]是构造数组[ab, cd]得到 1×2 string 数组而不是 abcd要真正拼成一个字符串得用ab cd。更隐蔽的是对 char 的行为a b不是拼接而是两个字符的 Unicode 码值相加9798195。这在老代码里偶尔会作为奇技淫巧出现但对维护者极不友好。所以我在代码规范里要求团队新代码一律用 string 加拼接老代码里如果看到[]拼接 char先确认操作数类型再决定要不要改成 append。strcat 和 append 对两类输入都支持但在混用场景下我更推荐 append因为它在 R2016b 之后语义统一不容易出现 strcat 对 cellstr 和 char 表现不一致的问题。2.3 比较与匹配 对 char 是逐字符比较比较文本是否相等老 MATLAB 代码几乎全用 strcmp / strcmpi这是有原因的。strcmp(abc, a) 返回逻辑标量 0安全又直观。但如果直接用char 数组的比较是逐元素进行的abc a在维度不一致时直接报错abc abd返回[1 1 0]逻辑向量放进 if 条件里就会报条件必须是标量逻辑值。string 数组引入后的语义被改善了很多对于 string 数组是逐元素比较字符串内容两个标量 string 比较结果是一个标量逻辑值。也就是说string 可以放心用。但当一块代码里既有 char 又有 string比如表格某一列是 cellstr、另一列是 string直接用就可能出现标量与矩阵比较的维度问题。我的习惯是数据进入业务逻辑之前先用 ischar、isstring 判一次类型统一转成 string后面全部用、contains、startsWith 这些现代函数。2.4 格式化与正则返回类型不统一sprintf 到现在也还是返回 char 数组如果你想要 string 格式化的结果得用 compose。我见过不少人在 sprintf 之后又包一层 string()这纯属绕路直接 compose 省事得多。regexp 这个函数也值得一提对 char 数组输入时默认返回数值索引数组对 string 数组输入时行为会变成逐字符串处理输出通常是 cell 数组。如果你在两种输入上复用同一套后续代码大概率要出幺蛾子。我把 char 和 string 在常见操作上的差异整理成一个快速对照表操作charstring创建hellohello取首字符s(1)extractBefore(s, 2) 或 char(s)(1)水平拼接[a,b] 得到 ab[a,b] 得到 1×2 数组字符串连接strcat(a,b)a b相等比较推荐 strcmp推荐 或 strcmp逐元素比较abcabd 返回逻辑向量abcabd 返回逻辑标量长度length 返回字符数strlength 返回每段文本长度格式化sprintf 返回 charcompose 返回 string缺失值没有用 表示空串用 这张表建议收藏写代码前扫一眼能省掉不少调试时间。3. 转换与互操作char、string、cellstr 的铁三角3.1 转换函数全家福实际工程里我们经常同时和三种形式打交道char 矩阵、string 数组、cell 数组每个元素存一个 char 行。它们之间的转换关系可以这样理解转换目标常用代码注意事项标量 string 转 charchar(s)s 是长度大于 1 的 string 数组时会生成字符矩阵并自动补空格char 转 stringstring(ch)单个 char 行向量转为 1×1 stringchar 矩阵按行转成多个元素char 矩阵转 cellstrcellstr(ch)按行切分每行转成一个 cell 元素cellstr 转 stringstring(cellStr)表格数据处理中非常常用string 转 cellstrcellstr(s)逐元素转成 cell 中的 char 行cell 转 char 矩阵char(cellStr)元素长度不等时自动补空格容易产生隐性问题有一个函数很多人不熟convertCharsToStrings 和 convertStringsToChars。这是 R2016b 推出的递归转换函数能把 struct、cell、数组里的 char 全部转成 string或反向转回。对老代码接口对接非常有用。比如你调用一个只接受 char 的老函数可以先 convertStringsToChars 一把梭把传入数据安全转换成 char 体系等函数返回后再转回 string。3.2 文件路径、表格列名与参数解析的实操以一个我常写的读数据流程为例。readtable 读进来的文本列在不同版本里可能是 cellstr也可能是 string 数组。后续如果要 contains 筛选列名我一般这样统一data readtable(data.csv); colnames string(data.Properties.VariableNames); target colnames(contains(colnames, 温度));如果不转成 string就得写 cellfun((x) contains(x, 温度), colnames)虽然也能跑但可读性和扩展性差不少。再比如写一个函数参数既要兼容 string 又要兼容 char。用 arguments 块可以声明合适的类型约束function out processText(str) arguments str {mustBeTextScalar(str)} end % 业务逻辑 endmustBeTextScalar 这个校验函数同时接受 char 向量和标量 string比单纯用 ischar 或 isstring 覆盖面广。这是老代码迁移到新风格时很值得引入的一个校验工具。3.3 转换背后的隐藏空格与缺失值char(string_array) 遇到长度不一的字符串时会自动在短行末尾补空格这个行为极易引发看起来一样、实际不一样的问题。举个例子char([ok, ops]) 得到 2×3 字符矩阵第一行实际上是 ok 末尾带一个空格。拿这行去和 ok 比较永远不相等。遇到这种情况要么直接保持 string 数组要么用 deblank 或 cellstr 处理掉行尾空格。missing值也有自己的陷阱。string 数组里的missing元素用 char 转换后会变成空 char但这个空不能再转回missing。如果你的处理流程里有补齐缺失值的逻辑务必在转换前集中处理 missing别转完再找那时类型信息已经丢了。另外要注意空 string 和missing是两码事判断时要用 ismissing(s)而不是s 。这些都是我用错过、回头翻文档才反应过来的细节写在这里给大家提个醒。4. 实际选型与迁移经验什么场景用哪套以及我踩过的坑4.1 选型思考别被新的一定好带偏string 更现代但绝不是所有场景都该用。我总结了一个比较实用的选择清单场景推荐类型理由字符级处理编码、加密、逐字节分析char数组索引直接、切片自然高频格式化输出char sprintf老函数稳定生态成熟大批量文本筛选、替换、匹配stringcontains / extract / startsWith 体验流畅表格数据变量名、标签string与 readtable、write table 现代 API 兼容MEX 接口、老工具箱参数char接口契约通常是 char路径处理、文件拼接两者都行fullfile 自动兼容具体到我的实践深度学习样本的标签管理我全用 string通信协议解析、字节流拆包全用 char。前者的核心是文本语义后者的核心是字节数组语义。选型方向对了后面能少返工。4.2 老旧代码迁移到 string 的操作清单如果你的老脚本还在大量使用 cellstr、strcat、ischar想向 string 靠拢建议按这个顺序操作先用 isstring、ischar、iscellstr 给代码里所有文本变量打点跑一遍程序看清楚文本数据是怎么流动的。把外部读入环节统一readtable、fileread、webread 读进来的文本尽早用 convertCharsToStrings 一次性转成 string。把内部计算环节改成 string 操作重点检查三处索引、拼接、比较。把对外输出环节明确转回目标格式比如 sprintf 或 char不要偷懒省略转换函数。我一次实际迁移中就是漏了第二步数据读进来还是 cellstr筛选逻辑已经改成 string结果 contains(cellArray, 关键词) 返回 cellcontains(stringArray, 关键词) 返回 logical一会儿逻辑数组一会儿 cell程序在 if 和 find 处直接崩了。后来在数据读入之后立刻 string(data.X)问题就消失了。迁移这种事边界转换越早做越省心。4.3 性能实测string 并不慢反复转换才慢有些老程序员坚持用 char理由是 string 有对象开销会慢。早期 R2016b 的 string 确实性能一般但后续版本做了大量优化。我自己做过简单对比生成一万行日志的场景纯 char sprintf 和纯 string compose 的耗时差距在 10% 以内而 string 版本代码更短、可读性更好。真正拖慢性能的是在循环里反复做类型转换。比如有人喜欢在循环体内不断 char(s)、string(ch)、再比较这种转换开销比两类操作本身的性能差距大得多。正确做法是把类型转换挤出循环循环外统一转好循环体内只操作同一类型。如果函数边界必须接收 char那就在函数入口和出口各转一次不要在循环里反复横跳。4.4 一个真实项目里的 陷阱复盘今年上半年我们有个参数校验脚本写法是 if method update。以前调用方传 charmethod 是单个字符时update 是 1×6 数组逐元素比较维度不匹配这段代码从来没真正被跑到。后来有人把调用方传参从 char 改成了 stringmethod 变成标量 stringif method update 终于能正常执行了结果分支里维护很久的逻辑立刻暴露了另一个 bug。这个案例说明比较运算符的语义随输入类型变化这本身就是代码的隐患源头。我的建议是业务参数在入口统一转成 string所有相等判断固定用 或 strcmp 的一种不要混用迁移过程中要对以前从未被执行过的分支保持警惕那往往是休眠 bug 的温床。5. 一点经验我在项目里给团队定的 char/string 混用规矩5.1 入口统一、出口转换项目做到后期最影响维护效率的不是某个函数写得烂而是文本类型在整个代码库里没有明确纪律。我给团队定的规矩很简单所有公开函数的文本参数在入口处统一转成 string内部逻辑只用 string 操作输出时按调用方需求明确转换。这样做的代价是每个函数入口多一两行类型判断代码但收益很明显。新同事接手代码时不需要一点点追踪某个变量到底是 char 还是 string只要看函数签名附近的统一转换就知道内部约定。文本类型相关的隐性 bug 数量明显下降。5.2 推荐一套小而美的工具函数基于这个约定我们封装了两个小函数function s ensureText(x) % 统一转 string兼容 char、string、cellstr if isstring(x) s x; elseif ischar(x) || iscellstr(x) || iscell(x) s string(x); else error(输入必须为char、string或cellstr); end end另一个是输出侧用的function c ensureChar(x) % 统一转 char常用于调用旧版接口 if ischar(x) c x; else c char(x); end end别小看这两个工具函数它们把全项目里大量重复的 ischar / isstring 判断收敛到了一处。后续如果官方再更新文本类型的行为只需要改这两个函数。5.3 最后分享一个自查习惯我每次写完一段涉及字符串的代码都会刻意做三件事先看引号是单引号还是双引号确认类型再看用到的索引和拼接函数是不是匹配该类型最后用 whos 或 isstring 快速验证一下变量类型。这个方法看起来很笨但确实帮我避免了不少跨类型比较的低级错误。尤其是从网上复制来的片段粘贴进工程时一定要先检查引号和函数兼容性很多隐蔽问题都是这么混进来的。文本处理在 MATLAB 里属于看起来简单、细究全是细节的领域。char 和 string 两套体系会一直并存下去与其抱怨官方不统一不如把两者差异和转换路径彻底吃透。希望这篇内容能帮你少走几步弯路。 
长河君 · 2026/10/14 7:56:00 · 阅读 1.2k MATLAB文本处理必知：char与string字符串类型对比与迁移指南
带过几个MATLAB项目之后我发现一个有趣的现象刚接触文本处理的人几乎都会被单引号和双引号的区别搞晕一次。hello 在 MATLAB 里是 1×5 的 char 数组而 hello 是 1×1 的 string 对象前者 ischar 返回 1后者 isstring 返回 1。同一串字符索引、拼接、比较的规则却完全不一样代码里混用起来非常容易踩坑。这篇内容就围绕 MATLAB 中 char 和 string 这两套文本体系展开把它们的底层逻辑、行为差异、转换方法、迁移经验一次讲清楚适合刚开始用 MATLAB 写文本处理脚本的新人也适合维护着一堆老代码、想把部分逻辑迁到新 API 的开发者。1. 两套体系的由来从一切皆矩阵到独立字符串对象1.1 char 的本质是字符数组不是字符串在 MATLAB 的初始世界观里一切数据都是矩阵char 就是这种哲学的直接产物。单引号 hello 创建的是一个 1×5 的 char 行向量每个元素是单个字符。类型名是 char但它和 C/C 里那个 char 完全不是一回事它天然具备数组的全部属性。你可以把它当普通矩阵来操作hello(1) 取第一个字符 hhello(1:3) 取出 heldouble(A) 可以得到 65char(65) 又能变回 A。这些行为说明 char 与数值矩阵用的是同一套底层模型每个字符本质上就是 Unicode 码元在内存里按 UTF-16 编码占两个字节。正因为 char 是数组它才有一堆数组的病。比如用 [abc; def] 能建一个 2×3 字符矩阵但如果两行长度不一样写成 [abc; de]MATLAB 直接报错你必须手动补空格让每行等长。这种处理方式对写惯 Fortran 和 C 固定长度字符数组的老程序员来说很熟悉但对新用户就非常反直觉。1.2 string 是 R2016b 才有的亲儿子由于 char 的数组语义在文本处理上太别扭MathWorks 在 R2016b 引入了真正的 string 类型。双引号 hello 创建的是一个 1×1 的字符串数组标量它每个元素都是一个完整的字符串对象可以包含任意长度包括 0 个字符的文本。string 的形态和 char 有本质区别它看起来也是数组但元素不是字符而是字符串。[apple, banana] 是 1×2 的字符串数组两个元素分别是 apple 和 banana。它和 C 的 std::string、Java 的 String 有点像但更接近一个字符串的向量容器。通俗理解char 是按字符排列的多维数组string 是按文本条目收纳的容器。string 还引入了missing这个显式缺失值标记空字符串用表示。这两件事在 char 的世界里都只能用空数组将就语义不够清晰。这些设计明显是在为表格数据、文本分析和现代 API 铺路。1.3 都发展这么多年了为什么还是两套并存按常理有了新类型旧类型就该退居二线。但 MATLAB 不可能这么做几十年积累的历史代码、工具箱内部实现、MEX 接口、Simulink 模块参数全部建立在 char 之上。官方如果强行抛弃整个生态就得重构这是不现实的。所以现实就是官方文档推荐优先使用 string但几乎所有底层工具箱对 char 的支持依然稳固而且很多函数的默认行为就是产生 char。fprintf 的格式控制、文件读取函数 fgetl、老式 GUI 回调参数传递这些场景到现在依然输出 char。我们做项目时没法只选其一必须两套都掌握并且随时注意边界上的兼容性。这也是我写这篇文章的直接动机。2. 操作行为差异同一个操作结果可能完全不一样2.1 索引与修改string 取首字符不是 s(1)这是新手最常踩的坑。对 char 数组s MATLABs(1)返回 Ms(4)返回 L把s(1) m还能直接改数组里的字符这就是数组的常规用法。对 string 数组就不一样了。s MATLABs(1)返回的是整个字符串 MATLAB不是首字符。想要首字符你得先char(s)再索引或者用 extractBefore、extractBetween 这类文本提取函数。而且 string 元素本身是不可变的你没法像改 char 数组那样原地改某一位字符想修改就得用 replace、extractBefore 等函数生成新字符串再赋值回去。这个差异不是小事在高频循环里把 string 当 char 索引轻则逻辑错误重则数组维度直接爆炸。举一个我见过的真实错误。有人遍历文件名数组时写了files [a.log, b.log, c.log]; for i 1:numel(files) prefix files(i, 1); % 本意是想取第一个字符 a end结果 prefix 一直等于整个文件名后面所有比较全部错乱。如果 files 是 char 矩阵或 cellstrfiles(i,1)才真的是取出第 i 行第一列字符。这个例子我讲给过不少同事大家几乎都中过招。2.2 拼接[] 和 对两套体系是两种玩法文本拼接是日常刚需但这里的坑最多。对 char 数组[]是水平拼接[ab, cd]和[ab cd]等价直接得到 abcd。对 string 数组[]是构造数组[ab, cd]得到 1×2 string 数组而不是 abcd要真正拼成一个字符串得用ab cd。更隐蔽的是对 char 的行为a b不是拼接而是两个字符的 Unicode 码值相加9798195。这在老代码里偶尔会作为奇技淫巧出现但对维护者极不友好。所以我在代码规范里要求团队新代码一律用 string 加拼接老代码里如果看到[]拼接 char先确认操作数类型再决定要不要改成 append。strcat 和 append 对两类输入都支持但在混用场景下我更推荐 append因为它在 R2016b 之后语义统一不容易出现 strcat 对 cellstr 和 char 表现不一致的问题。2.3 比较与匹配 对 char 是逐字符比较比较文本是否相等老 MATLAB 代码几乎全用 strcmp / strcmpi这是有原因的。strcmp(abc, a) 返回逻辑标量 0安全又直观。但如果直接用char 数组的比较是逐元素进行的abc a在维度不一致时直接报错abc abd返回[1 1 0]逻辑向量放进 if 条件里就会报条件必须是标量逻辑值。string 数组引入后的语义被改善了很多对于 string 数组是逐元素比较字符串内容两个标量 string 比较结果是一个标量逻辑值。也就是说string 可以放心用。但当一块代码里既有 char 又有 string比如表格某一列是 cellstr、另一列是 string直接用就可能出现标量与矩阵比较的维度问题。我的习惯是数据进入业务逻辑之前先用 ischar、isstring 判一次类型统一转成 string后面全部用、contains、startsWith 这些现代函数。2.4 格式化与正则返回类型不统一sprintf 到现在也还是返回 char 数组如果你想要 string 格式化的结果得用 compose。我见过不少人在 sprintf 之后又包一层 string()这纯属绕路直接 compose 省事得多。regexp 这个函数也值得一提对 char 数组输入时默认返回数值索引数组对 string 数组输入时行为会变成逐字符串处理输出通常是 cell 数组。如果你在两种输入上复用同一套后续代码大概率要出幺蛾子。我把 char 和 string 在常见操作上的差异整理成一个快速对照表操作charstring创建hellohello取首字符s(1)extractBefore(s, 2) 或 char(s)(1)水平拼接[a,b] 得到 ab[a,b] 得到 1×2 数组字符串连接strcat(a,b)a b相等比较推荐 strcmp推荐 或 strcmp逐元素比较abcabd 返回逻辑向量abcabd 返回逻辑标量长度length 返回字符数strlength 返回每段文本长度格式化sprintf 返回 charcompose 返回 string缺失值没有用 表示空串用 这张表建议收藏写代码前扫一眼能省掉不少调试时间。3. 转换与互操作char、string、cellstr 的铁三角3.1 转换函数全家福实际工程里我们经常同时和三种形式打交道char 矩阵、string 数组、cell 数组每个元素存一个 char 行。它们之间的转换关系可以这样理解转换目标常用代码注意事项标量 string 转 charchar(s)s 是长度大于 1 的 string 数组时会生成字符矩阵并自动补空格char 转 stringstring(ch)单个 char 行向量转为 1×1 stringchar 矩阵按行转成多个元素char 矩阵转 cellstrcellstr(ch)按行切分每行转成一个 cell 元素cellstr 转 stringstring(cellStr)表格数据处理中非常常用string 转 cellstrcellstr(s)逐元素转成 cell 中的 char 行cell 转 char 矩阵char(cellStr)元素长度不等时自动补空格容易产生隐性问题有一个函数很多人不熟convertCharsToStrings 和 convertStringsToChars。这是 R2016b 推出的递归转换函数能把 struct、cell、数组里的 char 全部转成 string或反向转回。对老代码接口对接非常有用。比如你调用一个只接受 char 的老函数可以先 convertStringsToChars 一把梭把传入数据安全转换成 char 体系等函数返回后再转回 string。3.2 文件路径、表格列名与参数解析的实操以一个我常写的读数据流程为例。readtable 读进来的文本列在不同版本里可能是 cellstr也可能是 string 数组。后续如果要 contains 筛选列名我一般这样统一data readtable(data.csv); colnames string(data.Properties.VariableNames); target colnames(contains(colnames, 温度));如果不转成 string就得写 cellfun((x) contains(x, 温度), colnames)虽然也能跑但可读性和扩展性差不少。再比如写一个函数参数既要兼容 string 又要兼容 char。用 arguments 块可以声明合适的类型约束function out processText(str) arguments str {mustBeTextScalar(str)} end % 业务逻辑 endmustBeTextScalar 这个校验函数同时接受 char 向量和标量 string比单纯用 ischar 或 isstring 覆盖面广。这是老代码迁移到新风格时很值得引入的一个校验工具。3.3 转换背后的隐藏空格与缺失值char(string_array) 遇到长度不一的字符串时会自动在短行末尾补空格这个行为极易引发看起来一样、实际不一样的问题。举个例子char([ok, ops]) 得到 2×3 字符矩阵第一行实际上是 ok 末尾带一个空格。拿这行去和 ok 比较永远不相等。遇到这种情况要么直接保持 string 数组要么用 deblank 或 cellstr 处理掉行尾空格。missing值也有自己的陷阱。string 数组里的missing元素用 char 转换后会变成空 char但这个空不能再转回missing。如果你的处理流程里有补齐缺失值的逻辑务必在转换前集中处理 missing别转完再找那时类型信息已经丢了。另外要注意空 string 和missing是两码事判断时要用 ismissing(s)而不是s 。这些都是我用错过、回头翻文档才反应过来的细节写在这里给大家提个醒。4. 实际选型与迁移经验什么场景用哪套以及我踩过的坑4.1 选型思考别被新的一定好带偏string 更现代但绝不是所有场景都该用。我总结了一个比较实用的选择清单场景推荐类型理由字符级处理编码、加密、逐字节分析char数组索引直接、切片自然高频格式化输出char sprintf老函数稳定生态成熟大批量文本筛选、替换、匹配stringcontains / extract / startsWith 体验流畅表格数据变量名、标签string与 readtable、write table 现代 API 兼容MEX 接口、老工具箱参数char接口契约通常是 char路径处理、文件拼接两者都行fullfile 自动兼容具体到我的实践深度学习样本的标签管理我全用 string通信协议解析、字节流拆包全用 char。前者的核心是文本语义后者的核心是字节数组语义。选型方向对了后面能少返工。4.2 老旧代码迁移到 string 的操作清单如果你的老脚本还在大量使用 cellstr、strcat、ischar想向 string 靠拢建议按这个顺序操作先用 isstring、ischar、iscellstr 给代码里所有文本变量打点跑一遍程序看清楚文本数据是怎么流动的。把外部读入环节统一readtable、fileread、webread 读进来的文本尽早用 convertCharsToStrings 一次性转成 string。把内部计算环节改成 string 操作重点检查三处索引、拼接、比较。把对外输出环节明确转回目标格式比如 sprintf 或 char不要偷懒省略转换函数。我一次实际迁移中就是漏了第二步数据读进来还是 cellstr筛选逻辑已经改成 string结果 contains(cellArray, 关键词) 返回 cellcontains(stringArray, 关键词) 返回 logical一会儿逻辑数组一会儿 cell程序在 if 和 find 处直接崩了。后来在数据读入之后立刻 string(data.X)问题就消失了。迁移这种事边界转换越早做越省心。4.3 性能实测string 并不慢反复转换才慢有些老程序员坚持用 char理由是 string 有对象开销会慢。早期 R2016b 的 string 确实性能一般但后续版本做了大量优化。我自己做过简单对比生成一万行日志的场景纯 char sprintf 和纯 string compose 的耗时差距在 10% 以内而 string 版本代码更短、可读性更好。真正拖慢性能的是在循环里反复做类型转换。比如有人喜欢在循环体内不断 char(s)、string(ch)、再比较这种转换开销比两类操作本身的性能差距大得多。正确做法是把类型转换挤出循环循环外统一转好循环体内只操作同一类型。如果函数边界必须接收 char那就在函数入口和出口各转一次不要在循环里反复横跳。4.4 一个真实项目里的 陷阱复盘今年上半年我们有个参数校验脚本写法是 if method update。以前调用方传 charmethod 是单个字符时update 是 1×6 数组逐元素比较维度不匹配这段代码从来没真正被跑到。后来有人把调用方传参从 char 改成了 stringmethod 变成标量 stringif method update 终于能正常执行了结果分支里维护很久的逻辑立刻暴露了另一个 bug。这个案例说明比较运算符的语义随输入类型变化这本身就是代码的隐患源头。我的建议是业务参数在入口统一转成 string所有相等判断固定用 或 strcmp 的一种不要混用迁移过程中要对以前从未被执行过的分支保持警惕那往往是休眠 bug 的温床。5. 一点经验我在项目里给团队定的 char/string 混用规矩5.1 入口统一、出口转换项目做到后期最影响维护效率的不是某个函数写得烂而是文本类型在整个代码库里没有明确纪律。我给团队定的规矩很简单所有公开函数的文本参数在入口处统一转成 string内部逻辑只用 string 操作输出时按调用方需求明确转换。这样做的代价是每个函数入口多一两行类型判断代码但收益很明显。新同事接手代码时不需要一点点追踪某个变量到底是 char 还是 string只要看函数签名附近的统一转换就知道内部约定。文本类型相关的隐性 bug 数量明显下降。5.2 推荐一套小而美的工具函数基于这个约定我们封装了两个小函数function s ensureText(x) % 统一转 string兼容 char、string、cellstr if isstring(x) s x; elseif ischar(x) || iscellstr(x) || iscell(x) s string(x); else error(输入必须为char、string或cellstr); end end另一个是输出侧用的function c ensureChar(x) % 统一转 char常用于调用旧版接口 if ischar(x) c x; else c char(x); end end别小看这两个工具函数它们把全项目里大量重复的 ischar / isstring 判断收敛到了一处。后续如果官方再更新文本类型的行为只需要改这两个函数。5.3 最后分享一个自查习惯我每次写完一段涉及字符串的代码都会刻意做三件事先看引号是单引号还是双引号确认类型再看用到的索引和拼接函数是不是匹配该类型最后用 whos 或 isstring 快速验证一下变量类型。这个方法看起来很笨但确实帮我避免了不少跨类型比较的低级错误。尤其是从网上复制来的片段粘贴进工程时一定要先检查引号和函数兼容性很多隐蔽问题都是这么混进来的。文本处理在 MATLAB 里属于看起来简单、细究全是细节的领域。char 和 string 两套体系会一直并存下去与其抱怨官方不统一不如把两者差异和转换路径彻底吃透。希望这篇内容能帮你少走几步弯路。