问题原因分析 #

首先咱们得把几个换行符的核心概念理清楚：

• vbCrLf 是Windows系统标准的换行组合：回车(CHAR(13)) + 换行(CHAR(10))，也就是\r\n
• vbNewLine 是.NET封装的平台无关换行符，在Windows环境下它本质上和vbCrLf等价，但它通过Environment.NewLine实现，会自动适配当前操作系统的换行规则

你遇到的矛盾情况（调试时能看到换行，赋值给TextBox后消失），最可能的原因有两个：

1. 存储过程的换行序列可能不符合标准
   虽然你说用了CHAR(13)和CHAR(10)，但有没有可能写反顺序了？比如写成了CHAR(10)+CHAR(13)（也就是\n\r）？这种非标准的换行序列，调试器的放大镜可能仍会显示换行，但WinForm的TextBox控件对它的识别度极低，自然不会换行。
2. TextBox内部处理更偏好平台标准换行符
   理论上vbCrLf和vbNewLine在Windows下等价，但如果字符串里的vbCrLf是从数据库读取的外部内容，可能会因为编码或隐式转换问题，被拆成两个独立的控制字符，而非完整的换行序列。这时候替换成vbNewLine（即Environment.NewLine），就能让控件正确识别。

解决办法 #

根据你的场景，给你几个可行的方案：

方案1：统一替换为Environment.NewLine（最直接）

既然替换操作已经生效，你可以在赋值给TextBox前，把所有可能的换行格式都统一为平台标准：

' 先处理单独的换行/回车，再处理组合序列，避免重复替换
myString = myString.Replace(vbLf, Environment.NewLine)
myString = myString.Replace(vbCr, Environment.NewLine)
myString = myString.Replace(vbCrLf, Environment.NewLine)
myTextBox.Text = myString

这样不管字符串里的换行是哪种格式，都能被TextBox正确识别。

方案2：修正存储过程的换行逻辑

如果是存储过程里的换行顺序写反了，直接修改存储过程代码，把CHAR(10)+CHAR(13)改成CHAR(13)+CHAR(10)，返回标准的Windows换行序列，后续赋值给TextBox时就不需要额外处理了。

方案3：直接赋值给TextBox的Lines属性

跳过控件对Text属性的换行解析，直接把字符串分割成行数组赋值：

myTextBox.Lines = myString.Split({vbCrLf, vbCr, vbLf}, StringSplitOptions.RemoveEmptyEntries)

这种方式兼容性更强，不管换行符是什么格式，都能准确拆分出每一行。

方案4：检查TextBox的基础属性

别忽略控件的基础设置：

• 确保Multiline属性设为True（这是多行显示的前提）
• AcceptsReturn设为True（虽主要影响用户输入，但对显示换行有辅助作用）
• 如果WordWrap设为False，超出宽度的内容会横向滚动，可能看起来没换行，调整为True即可自动换行显示。

内容的提问来源于stack exchange，提问作者Johannes Wentu