每个新计划启动前，我们团队内部总要开个简短的“技术选型会”。核心议题往往很聚焦：这个新活儿，到底该用Python+Qt（PySide6）上，还是派C#+WPF出马？
这俩都是我们的主力兵器，没有绝对的好坏，只有合不合适。选错了，后期能把自己和客户都折腾得够呛；选对了，项目顺风顺水，你好我好大家好。
怎么选？我们不空谈技术，就围着项目本身问几个最实际的问题。
第一步：先看任务“出身”，再谈技术
在考虑技术之前，得先把该计划的“底细”摸清楚。
谁用？在哪儿用？—— 使用人员与环境
场景A：产线工控机：操作员每天8小时盯着，软件要极其稳定，界面清晰直观，不能卡顿或崩溃。环境是固定的Windows 10/11。
场景B：实验室或调试终端：工程师或研究人员使用，要求灵活部署参数、跑算法、看日志。环境可能不统一，有时还需要在Linux下运行。
场景C：客户展示端：给客户或领导做演示，界面要酷炫，有动画效果，能快速修改演示逻辑。
核心是“业务”还是“算法”？—— 项目本质
业务密集型：软件核心是困难的工艺流程控制、大量的设备通信（PLC、仪表、机器人）、数据录入、报表生成。逻辑困难，但对实时计算要求没那么变态。
算法密集型：软件核心是视觉检测、数据预测、信号处理等。需要频繁调用OpenCV、TensorFlow/PyTorch、NumPy等库。算法模型的验证和迭代是主要工作。
算法从哪儿来？—— 协作模式
客户提供算法模型：客户的研究员给的是Python训练的.pth或.h5模型，我们只是调用。这时用Python能省去大量模型转换的麻烦。
我们从零创建算法：需要快速尝试各种算法库，Python的生态能让大家“站在巨人肩膀上”。
混合开发：核心算法由客户团队用Python研发，我们负责集成到完整的控制软件中。
未来会不会“搬家”？—— 部署与跨平台需求
钉子户：客户明确表示，未来5-10年都会是Windows系统，没有迁移计划。
潜力股：客户有国产化替代需求，未来可能从Windows迁移到国产Linux系统（如麒麟、统信UOS），甚至未来考虑适配鸿蒙。
客户有没有“指定动作”？—— 硬性要求
最高指令，没得商量。就是有些大客户或特定行业，由于内部技术栈、团队技能或历史原因，会明确要求必须采用C#或Java。这点
第二步：两大高手的优缺点对决
把上面五个问题问清楚了，技巧栈的选择方向基本就清晰了。现在我们来盘盘两位选手的家底。
一号选手：Python + Qt (以PySide6为代表)
- 优点（它的高光时刻）：
- 算法集成之王：这是它最硬的王牌。工业视觉、AI分析等项目，Python的生态（OpenCV, PyTorch, YOLO官方库等）是碾压级的存在。集成现成模型、调用最新算法库，效率极高。
- 真正的跨平台必选项。就是：一份代码，编译后可在Windows、Linux、macOS上原生运行。对于有国产Linux架构需求的方案，
- 开发迭代快：语法简洁，配合PyCharm等工具，写业务逻辑和算法验证速度极其快。适合快捷出Demo和原型。
- 缺点（它的吃瘪时刻）：
- 打包部署稍显笨重：打包成独立exe/可执行文件后体积较大，依赖管理必须细心处理。
- 执行性能有天花板：纯Python代码的计算性能不如C#/C++。对于UI渲染没问题，但遇到极端复杂、高频的实时数据运算（非底层库负责的部分），可能需要用C++写扩展。
- 大型工程管理有挑战：动态语言在超大型项目中的维护性，对架构和团队规范要求更高。
二号选手：C# + WPF
- 优点（它的统治领域）：
- Windows下的“贵族”：在Windows平台上，WPF应用的稳定性、性能和与系统的集成度是顶级的。部署容易，.NET框架装好即用。
- 工程化与大型项目神器：数据绑定和MVVM模式使得大型复杂UI的代码结构非常清晰，易于团队协作和长期维护，非常适合需要持续迭代的产线核心软件。
- 性能强劲：编译型语言，运行效率高，尤其擅长处理复杂UI和素材绑定，界面流畅度有保障。
- 缺点（它的局限）：
- 基本锁定Windows：WPF本身是Windows科技。虽然.NET本身可以跨平台，但WPF界面不能。跨平台需用Avalonia等框架，但生态和WPF本身有差距。
- 学习曲线稍陡：XAML和MVVM需要一定学习成本才能玩得转。
总结：我们的选型“心法”
说了这么多，最后给大家一个我们内部常用的“心法口诀”：
- 看见“视觉”、“AI”、“算法”、“Linux”、“飞快验证”-> 大脑优先指向Python + Qt。
- 看见“产线核心”、“7x24稳定”、“复杂数据界面”、“Windowsonly”、“长期维护”-> 大脑优先指向C# + WPF。
 ARM aarch64版 tcpreplay)
