@FlytoSirius 前几天刚把 CI 从 Jenkins 迁移到 Gitlab Pipeline 上。迁移的时候做了亿点点改造，改完之后基本和你说的一样，CI 仅负责基本调用，主要逻辑都在 Python 中实现。
Gitlab Pipeline 被触发后，设置一系列的环境变量，调用 Python 脚本。在 Python 脚本里做真正的工作：解析环境变量，编译，跑单测、归档啥的。
这样本地开发调试脚本也方便，后续迁移 CI 平台也更容易。

想起了去某个厂面试的经历。前几轮面试都是牛客网。最后 HR 面的时候，非得用自家公司的会议 app 。结果我登陆上去了，HR 半天没登录上，最后在微信完成了视频面试。
以及。。。似乎漏掉了用钉钉面试的公司。。。

主要做桌面端。用过 Qt5 、PyQt5 、Electron 、原生，调研过 Flutter 。

Qt5 性能接近原生，上手后开发速度其实很快的。QML 其实很不错，但是学的人用的人都太少，很多坑只能自己填。对各平台下的特性支持的一般，需要自己封装。如果用到了 Qt Web Engine，可能会遇到显卡兼容性相关的问题。
PyQt5 开发速度极快，但 PyInstaller 打包时不时的会出点幺儿子。以及 Python 本身的性能瓶颈，同样的动画效果，C++实现好不费力，Python 实现能跑满单个核心。
Electron 开发速度快，各平台下的特性支持全，开发到打包到分发到异常收集，都有完善的解决方案。社区活跃度很高，有啥需求 /bug，很快就能处理。唯一的缺点大概就是体积占用大，运行效率稍微低一点了。
Flutter 桌面端目前还是玩具，不建议自己去踩坑。

心中最理想的跨平台方案：核心业务逻辑用 C/C++实现。在各平台下用原生语言去实现界面交互和使用系统特性。但绝大部分场景下，不需要这么重的方案。
确定下公司当下是否真的需要跨平台方案，是否真的需要移动端和桌面端使用同一套方案。目前并没有哪套框架能够完美通吃桌面端和移动端。各个框架依然需要针对各个端进行适配开发。实际工作量并不比单独维护要小，甚至难度会更高。
快速出产品的话，桌面端除非有历史经验 /包袱，否则建议无脑 Electron 。移动端没有上线的项目，没有发言权。

凑合，月光，刚好够用。

wps/onedrive 上建个协作的表格，两个人把收入和支出都记录一下。月度年度做下汇总，看看哪块儿支出多，账上的钱和实际账户余额对不对的上。至于钱放哪边，我倾向于是谁更会管钱就交给谁。我家是放我媳妇那儿，让她买买基金啊理财产品啥的，不看收益多少，只求钱不莫名其妙的消失。
我和我媳妇已经这么实践了三年了。弊端大约是，媳妇会通过账单发现我偷偷喝奶茶不带她

用户想要使用服务（打电话 /流量传输等），提供实际服务的设备，在提供服务前，向计费系统发起鉴权请求。
计费系统根据用户权限、套餐、余额等信息，返回一个配额，告诉设备，可以先提供多少分钟通话时间 /多少兆的传输流量等。如果这些配额被用完后，用户还在使用服务，设备再重新发请求。
用户停止使用服务后，设备再告诉计费系统，最后一个配额用了多少。
中间如果遇到余额不足之类的情况，就直接返回鉴权失败。让设备终止服务。
大概的实现方式就是这样，实际的鉴权请求不会很大的。

看着像是安装或者编译 Qt 的时候，少了 webenginewidgets 的那部分。

os.walk 函数，topdown 参数设置为 False，就会从下往上遍历。
然后直接匹配文件 /目录名称，重命名就行了。

@TomeWong Electron 应该是主进程和渲染进程吧，之间用 IPC 通讯。
我们的客户端也是 Electron 实现的，计算 sha1 和上传都是放在 addon 里用 C 实现的。
这种 CPU 密集任务还是不要为难 js 了。

计算和上传的逻辑放到独立的子进程中去。
或者写个 addon，在 addon 中新建线程进行处理。

@nyanyh 虽然说都是基于 Chromium 内核，但 CEF 和 Electron 的上层封装完全不一样，无法复用。
即使使用同样的库，为了实现特殊需求，各家公司也会基于官方版本做一些小改动。比如说 Steam 用的 CEF，其实是自己定制的版本。不同的定制化版本之间也无法复用。
就算大家用的都是官方版本，但各家使用的 runtime 版本也不会一致。对于这种每一两周就会出更新一个稳定版的框架，要求开发商去适配自家的软件在各个版本的 runtime 下都能稳定运行是不现实的。甚至保证能在 runtime 最新版本下稳定运行这件事，都是很奢侈的。
最有可能实现的复用方案，就是楼上提到的 Microsoft Visual C++ Redistributable 那种，各个版本的 runtime 都来一份。然后期待某两个开发商的软件，用的 runtime 是同一个版本，能省下小几百兆的硬盘空间。

@xiri 那个貌似需要 win10 1607 及之后的系统，配合 Python 3.6 及之后的版本，才能正常处理。

这个应该是 windows 下特有情况。相关解释可以看一下
https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#maximum-path-length-limitation
你也可以看一下
https://qdebug.com/2019/07/31/Python3%E5%9C%A8Windows%E7%B3%BB%E7%BB%9F%E4%B8%8A%E5%AF%B9%E9%95%BF%E8%B7%AF%E5%BE%84%E7%9A%84%E6%94%AF%E6%8C%81/
之前我整理的一个文章。
想快速解决的话，可以试试把路径处理一下，所有的‘/’替换为 r‘\’，再在最前面加上 r‘\\?\’，作为新的路径，传入函数。

界面迁移到 Qt 上做，是因为底层调用的库是用 C 封装的，用 Qt 调用起来会更方便？还是别的什么原因？
给个思路供参考哈。
楼主可以考虑 C++甚至 C 入个门，然后看一下 Node js addon 相关的开发文档。
后续如果还留在公司，可以把公司的 C 库封装成 addon，在 electron 中调用。
如果换工作，简历上的经历也是连续且逐步深入的。

@sc3263 试一下 Qt5 里新的信号槽连接方式呗。那个会有编译期的类型检查。

以及。。。2020 年了

QObject::connect(
this, SIGNAL(tunnel::add_item_into_table_signal(std::string, std::string, std::string)),
this, SLOT(tunnel::add_item_into_table(std::string, std::string, std::string))
);

去掉这边的 tunnel::
如果还不行的话，调试模式启动，看看 Qt 本身有没有输出类似
QObject::connect: No such signal A::add_item_into_table_signal(std::string, std::string, std::string) in xxx.cpp
的日志