SQL Server 用 VARBINARY(MAX)，MySQL 用 MEDIUMBLOB 或 LONGBLOB，PostgreSQL 用 BYTEA；优先存原始字节而非 Base64 文本，避免截断、编码污染和额外解码开销。
Base64字符串该用什么数据库字段类型存？
直接说结论：SQL Server 用 VARBINARY(MAX)，MySQL 用 MEDIUMBLOB 或 LONGBLOB，PostgreSQL 用 BYTEA；如果非要用文本字段（比如 NVARCHAR(MAX)），必须确认 Base64 字符串没被截断、没被编码污染，且后续不打算做二进制操作。
Base64 是编码结果，本质是文本，但它的原始意图是传输/存储二进制数据。用文本类型存，等于多一层无意义的编码嵌套——你存的是“编码后的文本”，读出来还得再解码一次才能还原成字节，徒增出错环节。
-
VARBINARY(MAX)存的是原始字节流，Convert.FromBase64String()的输出可直插，Convert.ToBase64String()的输入可直取，零转换损耗 - 若误用
NVARCHAR(4000)，超长 Base64（比如一张 2MB 图片编码后约 2.7MB 字符）会被静默截断，读出来解码时报FormatException: Invalid length for a Base-64 char array - SQL Server 中
NVARCHAR(MAX)虽能存长文本，但 EF Core 默认映射byte[]到VARBINARY；若手动改成NVARCHAR，需同步改实体属性类型为string，否则运行时抛InvalidOperationException: Cannot convert string to byte[]
C#里怎么安全地把byte[]转成Base64再入库？
关键不是“怎么转”，而是“什么时候转”——绝大多数情况下，根本不该在 C# 层转 Base64 再存。直接传 byte[] 给数据库驱动，让参数化查询处理二进制更可靠。
常见错误是先 Convert.ToBase64String(bytes)，再塞进 SqlParameter 当 SqlDbType.NVarChar，这既浪费 CPU，又放大存储体积（+33%），还引入换行符风险（Base64 换行符 \n\r 不是标准要求，但某些编码器会加）。
- 用
SqlParameter时，显式指定SqlDbType.VarBinary，值设为原始byte[]，不要 ToString() 或拼接 - EF Core 中，实体属性声明为
public byte[] Data { get; set; }，配置 Fluent API：modelBuilder.Entity<x>().Property(e => e.Data).HasColumnType("varbinary(max)");</x> - 如果真要存 Base64 文本（如日志记录、调试场景），务必用
Convert.ToBase64String(bytes, Base64FormattingOptions.None)禁用换行，避免入库后含不可见控制字符
从数据库读byte[]再转回文件时，为什么总报“输入不是有效的 Base-64 字符”？
这个错误几乎全是文本字段惹的祸——你从 NVARCHAR 读出来的字符串，看着像 Base64，实际混入了空格、换行、BOM、或数据库自动截断后的残缺串。
典型诱因：前端传来的 Base64 数据带 data:image/png;base64, 前缀，后端没剥离就直接存；或者 SQL 查询用了 CONVERT(NVARCHAR(MAX), Data) 强转二进制字段，触发隐式编码（如 Windows-1252 → UTF-8 不兼容导致乱码）。
- 查库时用原生二进制字段，别 SELECT CAST(Data AS NVARCHAR) —— 这不是“查看”，这是“制造错误”
- 如果必须从文本字段读 Base64，先
Trim()去首尾空格，再检查长度是否为 4 的倍数，再用Convert.FromBase64String(s)；别跳过校验直接解码 - EF Core 中若字段映射为
string但底层是VARBINARY，会自动用 UTF-8 解码成字符串——这时读出来的根本不是 Base64，而是乱码，解码必崩
MySQL / PostgreSQL 用户特别注意的兼容点
MySQL 的 TINYBLOB 最大只支持 255 字节，一张小图标 Base64 解码后都可能超；PostgreSQL 的 BYTEA 默认用十六进制格式传输，但 Npgsql 驱动已自动处理，只要参数类型设对（NpgsqlDbType.Bytea），不用手动 hex_encode。
- MySQL 连接字符串务必加
Allow User Variables=True（旧驱动）或升级到 MySQL Connector/NET 8.0+，否则PARAMETERIZED二进制参数可能被当作文本解析 - PostgreSQL 中，别用
TEXT存 Base64——虽然能存，但 pgAdmin 显示时可能自动换行，复制出来粘贴进代码就多了 \n，Convert.FromBase64String()直接炸 - Docker 环境下 MySQL 容器默认
max_allowed_packet=4MB，上传大文件 Base64 解码后超限，会报MySqlException: Packet for query is too large，得调大并重启容器
最麻烦的从来不是“怎么写那几行代码”，而是字段类型选错之后，问题会藏在读写路径的任意一环里，等你上线跑一周才冒出来——那时连日志都看不出是字段类型的问题。
