建议：
1. 因为项目跨度太长，必然会产生屎山和各种风格不一致，还是调整心态吧。
2. 虽然“2022 年已经快到了，使用异步代码访问数据库完全不是什么行为艺术”，但项目不是 2022 年开始的，是周期长跨度到 2022 年的，不要给自己找麻烦去迁移异步了。如果是新项目可以。
3. 既然是海蛎子查询，那还是现实一点吧。

从你自己写的就可以看出来，更多的问题是因为，1.项目演进的问题 2.SA 跟你的项目的匹配度问题

至于 SA 本身的设计路线，当然也是个问题，但并不是跟你带来痛苦的关键

“大连表复杂查询”，会不会被分词引擎分出一股海蛎子味来……

至于担心非程序员抢了程序员饭碗啥的……想多了。

现在的海量 crudboy 所作的业务功能开发，也就是名义上算是个程序员，真干起活来，大部分工作都是在理解业务。其中有不少根本就没想好好学技术，只想着重业务、转管理。这样的人，用无代码平台去做业务实现，恐怕还是比用通用的编程语言更靠谱。毕竟在无代码平台上，就可以不用管技术细节，只“重业务”了。不用担心线程同步写错了死锁，不用发明“粘包”概念，不用手拼 SQL 字符串被搞死，不用被生产环境的运维怼不规范……

这些所谓的“程序员”其实就是来抢饭碗的非程序员，无代码对他们的未来更友好。担心个毛，会进来抢饭碗的，早就来了。

考虑到当代主流 crudboys 的水平和素养，以及主流架构师们热爱的臃肿肥大的技术栈，其实你对无代码工具的质量、性能、可维护性的担忧并不是什么大问题，毕竟人写的代码也好不到哪里去，甚至很有可能更糟糕。

@gridsah 好吧，我只是觉得，如果不是因为客户的原因，真的没必要坚持 RHEL （以及以尽量兼容 RHEL 为原则在没有 RHEL 的环境选择第二发行版），哪怕用年纪比较大不想折腾为理由。蓝帽厂能这样玩一次 CentOS 老用户群，以后就能玩出更多的幺蛾子。与其用这些 derivatives 妥协，不如及早抽身。

更看不到你必须在一个公网的 VPS 里用 RHEL 的理由。如果 RHEL 是你如痴如醉的坚定信念，那么砸钱买云服务大厂的贵 VM 。但是从你讲的来看，真没有必要坚持。

@gridsah 你洋洋洒洒一大串，看不到必须用 RHEL 的理由。

不如讲一讲你的原始动机。否则在你提出的几个互相矛盾的限制条件下大家也不可能给出又想马儿跑又想马儿不吃草的办法。在你没讲清楚之前，大家只会给一些自己觉得合理但不合你需求的意见，甚至沦落为发行版口水战。如果你能撸一下思路，讲清楚，也许你自己就排出来各个要求的优先级，放弃最不重要的限制条件了。

我能想到的一定要用 RHEL 的唯一原因是，你在开发给企业用的软件，客户自己的生产环境的要求必须是 RHEL……但，你要在 linode 上开服务器来跑，又希望 linode 跟你的开发环境一致，跟这个假设不太相符。

如果 RHEL 是刚需，那换个有 RHEL 的主机商嘛，不过肯定比用社区版系统的贵就是了。

我还是不太明白你们为啥把问题想得这么复杂。
这又不是让外面主动发起连接访问里面，说了是里面往外传数据了啊。
是不是互联网直连时代成长起来的青年纯程序员们根本不知道有代理服务器这个玩意，也对运维手段毫无概念啥都想通过自己开发来实现。

@Renco 那就自己装个 ats 或者 squid 或者 tinyproxy 好了，业务系统里设置跳板机作为 proxy 访问外面服务器的 http api…这是很基础的运维技能，根本不需要祭出重量级框架做开发。

@2i2Re2PLMaDnghL PyPy 也有 GIL……曾经尝试用 STM 来做一个无 GIL 的版本，然后没有下文了

如果业务代码都是你自己写，系统都是你自己装，没有特殊管理策略的话，难道不是在跳板机上安装一个普通的 http proxy 或者 socks5 proxy 就可以了吗？

矫情

@AndyAO Python 又不是以函数式范式为主的语言。Lambda 早期出现在 Python 里只是一种尝试而已。

@c0xt30a 缩进只是表象，Python 写 lambda 的主要问题不是书写不方便而是表达能力的限制。同样是缩进系语言，这跟 Haskell 和 ML 系的就是天壤之别了。

@murmur 长三角表示并不存在“国内基本健康码全身（？）微信的”情况…

龟叔说了 Python 不提倡 lambda ，之所以长期留着只是因为以前有 ^o^

不过 Python 的单行 lambda 虽然弱但还是能写出 Y-Combinator 来的。