不可见数字水印在纯文本文件中无法真正实现，因任何嵌入操作都会破坏语义合法性；图片LSB水印虽可行但易被压缩破坏，提取失败率高，生产环境仅适用于非对抗场景。
不可见数字水印在 C# 中无法真正“不可见”地嵌入纯文本文件；对图片可行，但必须接受画质微损、提取不稳定、抗攻击能力弱的事实。
为什么文本文件不适合嵌入不可见水印
纯文本（如 .txt、.csv）是语义敏感的字符序列，任何隐藏信息的操作都会破坏其可读性或合法性——比如修改空格/换行/Unicode零宽字符，本质是“可见”的格式污染，且极易被编辑器自动清理、传输过程丢弃、编码转换抹除。
- 常见错误现象：
ZeroWidthSpace在 Notepad++ 里显示为小方块，VS Code 默认不渲染，复制粘贴后消失 - 使用场景：仅适合临时内部标记，不能用于版权追踪或防伪
- 参数差异：用
\u200B（零宽空格）还是\u2060（单词连接符）不影响结果——都不可靠 - 性能 / 兼容性影响：无性能问题，但几乎所有文本处理链路（HTTP POST、日志采集、数据库入库）都会过滤掉这些字符
System.Drawing 图片 LSB 水印实操要点
主流做法是修改像素最低有效位（LSB），人眼难察觉，但需注意图像压缩会直接摧毁水印。
- 常见错误现象：
ArgumentException: Parameter is not valid.—— 源图被 WebP/JPEG 压缩过，或使用了索引色模式（PixelFormat.Format8bppIndexed） - 使用场景：仅适用于原始 PNG 或未压缩 BMP；JPEG 必须转成 PNG 再嵌入，且提取时仍大概率失败
- 参数差异：
Bitmap.SetPixel()性能极差，务必用LockBits+ 指针操作；水印数据建议 Base64 编码后转字节数组再嵌入 - 性能 / 兼容性影响：.NET 6+ 推荐用
ImageSharp替代System.Drawing（后者在 Linux 容器中可能崩溃）
简短示例（核心逻辑）：
fixed (byte* ptr = bits) {
for (int i = 0; i < watermarkBytes.Length && i * 8 < totalPixels; i++) {
for (int bit = 0; bit < 8 && i * 8 + bit < totalPixels; bit++) {
int pixelIndex = (i * 8 + bit) * 4; // RGBA
ptr[pixelIndex] = (byte)((ptr[pixelIndex] & 0xFE) | ((watermarkBytes[i] >> (7 - bit)) & 0x01));
}
}
}提取水印时最常忽略的三个细节
嵌入只是第一步，提取失败才是常态。问题几乎全出在“以为原图没变”上。
- 图像被微信/QQ/邮件客户端二次压缩 → 所有 LSB 位翻转，水印完全丢失
- 用
Bitmap.Save("out.jpg")导出 → JPEG 量化表重算，像素值已非原始值，提取结果随机 - 没校验水印长度头 → 提取时不知道该读多少字节，容易越界或截断；建议前 4 字节存 int32 长度，再跟数据
- 没加简单校验（如 XOR 校验和）→ 无法区分“提取失败”和“提取到乱码”
真正在生产环境用，得接受一个事实：没有通用、鲁棒、不可见的 C# 水印方案。LSB 对截图、转码、调色毫无抵抗力；而频域水印（DCT/DWT）在 .NET 生态缺乏轻量成熟库，自己实现极易出错。别指望它防专业盗图，只够应付随手保存的场景。
