我敢说楼主肯定只是安装并运行成功就算打完收工了。

在 AMD Rzyen 2400G 平台上 OpenSUSE + Lutris 肝了几个月 WOW 的表示，WOW 在 Linux 有个超级蛋疼的问题，不做处理，会在游戏过程随机出现错误并退出，需要从 Windows 上拷贝一份最新的 World of Warcraft/_retail_/Cache/WDB 覆盖到 Linux 下的路径才能解决这个问题。

不管技术是不是真的具有稀缺性，是老板，心里怎么想不重要，肯定要这样说；是员工，心里怎么写不重要，肯定要反对。

商用和家宽不一样，具体差异要看服务协议这些。当然，你觉得不值也没办法，因为没法选择。

如果没有什么合理的理由，比如大规模扩充人员架构各个层次都要之类的。那么，通常就是对行情不了解，又怕做冤大头，所以才这样讲——有点像网游里面打到个“极品”装备不知道开什么价的。反正用人方市场强势，大多数人也不能说什么。

至于那些实际能开的薪资比 JD 薪资下限还低很多的情况，我是完全搞不懂什么操作。

比烂，恰饭，常规操作。以后要是他发达了，就是情商高，敢拼，你这种人情商低，死板。

307/308，但是需要 http client 有实现。

改变不了什么，不过迷茫又不知道该做什么，那就先学着。

沃尔玛收银员——曾经在世界 500 强企业负责财务相关工作。

USB3.0 外置硬盘座

嗯，知道了。

这个不是一个完全的技术问题，需要建立在良好的设计之上才能解决。事实是不论如何做版本管理，最终落地都会对开发人员有水平要求，而人员成本直接决定了版本管理方案最终能不能实行下去。对于很多小公司，由于人员流动高，管理水平有限，一份代码复制 N 份，一个客户一个压缩包是常态。

当初我选择的方法是一个客户一个分支，然后可以合并的功能合并到主干，并做成可配置化，分支需要主干的功能时由对应负责的人去从主干合并到分支。数据库这边不使用所谓的保留字段，会造成同一个个字段不同客户有不同的业务意义，涉及到功能代码升级时无法平滑升级。

实际实践中仍然一堆问题，主要是合并代码时对操作的人要求比较高，分支负责人通常都图方便，选择直接复制粘贴对应代码解决。当主干功能模块出现 bug 修复后，无法找到合并记录，还得人肉再对比修复。后面经过几次人员更新，又变回压缩包解决的方式了。

后面我想明白了，在一定规模下，压缩包这种方式也确实可以有效降低人员要求和管理要求，也算是符合成本的解决方案。

这些 ERP 为了保证功能正常，有些就是需要暴露高危端口和服务的，开发商那边的技术支持也解决不了问题。

无论上上云还是部署防火墙其实出发点是一样的：认为只要这样做了问题自然会解决。

40 岁的中国人还要吃饭，现实吗？

找个人开发者无非就是看中价格和灵活，如果又来按对公那套标准，这个价格是不行的。

计算列可以满足要求，但是不一定能解决问题。

最简单的，ssms 导出旧库表数据成 sql 语句，新库执行一下。麻烦点的，新库跨库查询旧库语句插入到指定表。

根据业务需要，逻辑复制，CDC 什么的也可以考虑。

xy 问题

AI+大数据，在客户端发出请求之前就先返回不就可以把响应变成毫秒级了么 :doge:

没钱，但是麻烦点无所谓的话，推荐直接把数据库硬盘拆下来放保险柜。