既然string scalar是字符序列，为何仍需要character vector类型？

首先明确两类类型的本质差异 #

• 'abc'格式的character vector本身就是原生一维字符数组，属于MATLAB的基础数据类型，它的每个元素对应单个字符，支持和普通数值数组完全一致的索引、运算逻辑，比如执行'abc'(2)会直接返回'b'，double('a')可以直接获取字符对应的ASCII编码值。
• "abc"格式的string scalar是R2016b版本推出的容器类对象，不属于原生数组类型，它的内部封装了字符序列，你直接对string scalar做索引"abc"(1)拿到的还是完整的"abc"标量，无法直接获取单个字符，需要先转成char数组或者调用专用方法才能操作内部的字符。

你提到的“string scalar本质是字符组成的数组”是误解：它只是内部持有字符数组，本身的类型是容器对象，和原生char数组有本质区别。

两类类型共存的核心原因 #

• 历史兼容性
  MATLAB诞生后的几十年里都只有char类型作为字符存储方案，大量存量代码、内置函数、第三方工具包的接口都只支持char类型输入，比如早年的文件IO、绘图参数设置、MEX接口调用的逻辑都是基于char设计的，如果直接废弃char数组，所有存量代码都会失效，兼容性成本极高。
• 性能与开销差异
  char是原生数组，存储的是连续的编码值，没有额外的对象封装开销，处理短文本、需要直接操作字符编码的场景下，char的内存占用更低、运算速度更快，适合高性能计算、底层交互的场景。
• 行为逻辑适配不同场景
  char数组的操作逻辑和数值数组完全对齐，比如拼接多个char数组会直接合并成一个更长的字符数组，生成固定宽度的文本表格时，char数组会自动对短行补空格对齐，这类场景下用char比string更方便；而string类更适合处理多段可变长度的文本集合、支持更多字符串处理的专用方法，适合上层文本分析的场景，两类类型的设计目标本来就有差异。
• 底层交互的便利性
  和C/C++ MEX函数、操作系统API交互时，char数组的内存结构就是标准的字符序列，不需要额外解析就可以直接传递，而string作为封装类需要先拆封才能拿到底层字符序列，反而增加了交互成本。

内容的提问来源于stack exchange，提问作者William Wang