如果你也是写 .NET 的，大概率听过（甚至用过） PaddleOCRSharp：接起来快、上手顺，做个小工具/内部系统挺香。
我也一样，用过 PaddleOCRSharp（毕竟 .NET 圈里真省事）。
唯一值得庆幸的是：我没把它塞进生产环境。
不然这次可能就不是“吃瓜”，而是“吃席”。
事情大概是这样：一个 BUG，顺手把“稳定性”也一起优化了
最近有用户反馈：PaddleOCRSharp 6.0.0 免费版在某些场景下会触发强制关机。
尤其当你把它部署在：
-
服务器 -
工厂/产线设备 -
现场无人值守工控机 -
并且设置了开机自启
那体验就会非常“丝滑”：
开机 → 自启 →（体验一下）→ 关机
让设备学会了自我管理：不工作就不出错，主打一个从根源解决问题。
这种 BUG 的优点也很明显：
-
你不用排查内存泄漏 -
不用分析线程死锁 -
甚至不用看日志
因为它会直接把“继续讨论”这件事也一并终止
作者第二天很快就修复了
PaddleOCRSharp6.0.1版本发布：
修复1月3号自动关机的BUG。 ★该普通版将于2026年6月份失效。 ★PaddleOCRSharp普通版收费299元。
轻轻复盘：为什么“没上生产”这件事，突然显得很有含金量
我这次之所以后背发凉，是因为我完全能想象一种很常见、很合理、很“专业”的部署方式：
-
“OCR 服务嘛，放服务器上跑就行” -
“开机自启，保证可用性” -
“依赖更新一下，拿到最新修复” -
“反正只是个识别库，能有多大事”
逻辑都对。
唯一的问题是：工程世界里，“都对”不等于“都安全”。
生产环境最贵的地方，从来不是机器，而是它背后的业务链路。
而某些依赖最擅长的事情，就是在你“觉得无所谓”的那一瞬间，突然变得很有所谓。
给同样用 .NET、也可能用 PaddleOCRSharp 的朋友几个“温柔但有用”的建议
不是批评谁（我也用），就当是给未来的自己写备忘录：
1）锁版本，不要把“升级”做成抽盲盒
依赖能跑 ≠ 新版本能跑 ≠ 新版本在你环境能跑
更不等于“它不会带来你没想到的副作用”。
2）预发/灰度不是形式主义，是“把意外留在可控范围”
很多事故并不是因为问题太复杂，而是因为问题出现的位置太关键。
3）生产环境慎用带失效机制的版本
公告里也写得很清楚：普通版有失效时间、也有收费信息。
不讨论选择哪个版本，只说一个现实：
“会失效”的逻辑一旦进入生产，它就等于在系统里多埋了一颗定时器。
定时器响的时候，是不是一定会出事？不一定。
但它一旦响在关键节点，就会非常热闹。
4）把 OCR 当成“外部系统”来做隔离
哪怕只是一个识别库，也建议做边界：
超时、熔断、隔离进程、必要时容器化……
让问题停留在“服务不可用”，而不是“整机不可用”。
结尾：愿 PaddleOCRSharp 越来越好，也愿我们都别用生产环境“帮忙测试”
这次作者修复很及时，公告也很清晰，这是好事。
但对使用者来说，更重要的收获可能是：
提醒我们把“依赖管理”当成工程的一部分，而不是顺手的操作。
我会继续用 PaddleOCRSharp（它对 .NET 确实友好），
只是这次之后，会更认真地把它放在“该放的位置”。
毕竟：
-
OCR 的职责是识别文字 -
不是识别“关机键” -
更不是替我们做“断电演练”