尽管 Python 优势明显，但它并非万能。理解技术边界，能避免方向性错误，让合适的技术解决合适的问题。以下几个场景中，Python 通常不是最佳选择。
高性能底层系统
- 典型场景：操作系统内核、数据库引擎、高频交易系统、3D 游戏引擎。
- 不推荐的原因：
- Python 解释执行和动态类型的开销，使其原始计算速度远低于 C/C++、Rust 等编译型语言。
- 内存占用相对较高、对象访问存在间接性，对极致性能敏感的逻辑难以满足。
- 现实处理方式：不完全是“全不用”，而是“关键路径不用”。可以用 C/C++ 编写性能热点，封装成 Python 扩展；或者干脆将计算密集模块用其他语言实现，Python 仅做上层调度。
强实时性嵌入式
- 典型场景：汽车 ECU、医疗设备控制、航空航天飞控、工业机器人实时控制。
- 不推荐的原因：
- 强实时系统要求在确定的微秒/毫秒级时间内响应中断，而 Python 的垃圾回收机制和 GIL 会导致无法预测的执行暂停。
- Python 虚拟机本身占用内存和启动时间，在资源极度受限的单片机（如几千字节 RAM）上根本跑不起来。
- 现实处理方式：某些软实时或非安全关键场景，可以用 MicroPython 或 CircuitPython 在资源稍好、实时要求不苛刻的微控制器上做快速原型开发，但量产硬件最终往往还得回归 C。
重型客户端开发
- 典型场景：大型桌面软件（如 Photoshop、AutoCAD）、高性能 GUI 游戏客户端。
- 不推荐的原因：
- Python 的 GUI 库（如 tkinter、PyQt、wxPython）虽然可用，但打包成独立可执行文件体积庞大，启动慢，且 UI 性能、原生控件体验均不如 C++/Qt 组合或 .NET 框架。
- 缺乏统一的、工业级的 UI 开发标准，社区关注点更多在 Web 和数据领域。
- 现实处理方式：如果只是内部工具、小规模数据管理界面，用 Python 写个 PyQt 程序快速交付没问题。但大规模面向海量用户的桌面产品，目前依然优先考虑经过验证的原生方案。
理解这些局限，不是为了否定 Python，而是为了在选择技术方案时更理性：让 Python 做它最擅长的事，在边界外用更合适的工具接力。