我毫无保留的猜测是，大多数库编写者不想添加不必要的依赖项。由于字符串实际上是每个 Haskell 发行版的一部分（它是语言标准的一部分！），如果您使用字符串并且不需要您的用户从 hackage 中整理出 Text 发行版，那么它更容易被采用。
这是你不得不忍受的那些“设计错误”之一，除非你能说服大多数社区的人改过自新。看看 Applicative 成为 Monad 的超类花了多长时间——一个相对较小但非常需要的变化——想象一下用 Text 替换所有 String 的东西需要多长时间。
要回答您更具体的问题：除非您通过使用 Text 获得明显的性能优势，否则我会使用 String。错误消息通常是相当小的一次性事件，因此使用 String 应该不是什么大问题。
另一方面，如果您是那种为了理想主义而避开实用主义的意识形态纯粹主义者，请选择文本。
* 我将设计错误放在引号中，因为作为字符列表的字符串是一个简洁的属性，使它们易于推理并与其他现有的列表操作函数集成。
如果您的 API 旨在处理大量面向字符的数据和/或各种编码，那么您的 API 应该使用Text。
如果您的 API 主要用于处理小的一次性字符串，那么使用内置的String类型应该没问题。
对大量文本使用String将使使用您的 API 的应用程序消耗更多的内存。根据 API 的工作方式，将其与外部编码一起使用可能会使使用变得严重复杂。
字符串非常昂贵（至少 5N 个单词，其中 N 是字符串中的字符数）。一个字的位数与处理器架构相同（例如 32 位或 64 位）： http ://blog.johantibell.com/2011/06/memory-footprints-of-some-common-data.html
在小型项目中使用 [Char] 至少有三个原因。
[Char]不依赖任何神秘的工作人员，如外部指针、原始内存、原始数组等，它们在不同平台上的工作方式可能不同，甚至完全不可用
[Char]是哈斯克尔的通用语。在 haskell 中处理 unicode 数据至少有三种“有效”的方法：和utf8-bytestring，每一种都需要处理额外的包。Data.Text.TextData.Vector.Unboxed.Vector Char
通过使用[Char]一个可以访问[]monad 的所有功能，包括许多特定功能（替代字符串包确实试图帮助它，但仍然）
就个人而言，我认为基于utf16Data.Text的Haskell 社区最有问题的设计之一，因为utf16结合了utf8和utf32编码的缺陷，但没有任何好处。
我想知道 Data.Text 是否总是比 Data.String 更有效？？？
例如，“cons”对于字符串是 O(1)，对于文本是 O(n)。对于字符串，追加是 O(n)，对于严格文本，追加是 O(n+m)。同样地，
let foo = "foo" ++ bigchunk
bar = "bar" ++ bigchunk
字符串比严格文本更节省空间。
与效率无关的其他问题是模式匹配（清晰的代码）和惰性（可预测的字符串中的每个字符，以某种方式依赖于惰性文本的实现）。
文本显然适用于静态字符序列和就地修改。对于其他形式的结构编辑，Data.String 可能具有优势。
我不认为 String 存在的单一技术原因。我可以看到几个。
总的来说，我首先会争辩说，在 Text/String 的情况下，只有一个最佳解决方案：
弦乐表现不好，大家都同意
文字不难使用。String 上常用的所有函数都可以在 Text 上使用，另外还有一些在字符串上下文中更有用的函数（替换、填充、编码）
除非所有的基本函数都是多态的，否则有两个解决方案会产生不必要的复杂性。证明：有关于自动转换主题的 SO 问题。所以这是一个问题。
所以一种解决方案不如两种复杂，String 的缺点最终会使其消失。越早越好！