ddr5 要先换 CPU （基本上也必须先换主板），上面几个人瞎几把推荐。

理想情况下，2x16G 双通道 跟 4x8G 两个双通道，是没区别的。实际情况下，大多数主板 4 条内存插槽里面至少有 1 个被 CPU 风扇挡住了。就算没被挡，4 条内存插槽能全部正常工作的情况也很难。

双通道确实比单通道好，但是除了集显，基本上体验不出来。所以如果你有独显的话，单挑 32G 才是最不容易出先内存插槽问题的最优解。

我特意给开了 2FA 看了下，本站 2FA 没有救援码。丢了密钥（ TOTP SEED ），那就只能后台发邮件找站长了。

如果两步验证密钥丢了，同时没有或者也丢了其他两步验证方式或一次性复原码，那就直接扔帐号吧。两步验证是不能用已登录的用户或者用户名密码搞重置的，否则两步验证就成了笑话。

一般是 system engineer 系统工程师。senior 是形容词，一般不会参与专有名词的缩写。 另外不知道楼主哪里查的，Senior Engineer 这种未定范围的工程师，在国外这可是类似于 Doctor 、Professor 的高级头衔，并不会用于职业工种上。

@fang5566 #7 且不管法律层面根本不是你说得那样。就算是，那也犯了一个抛开剂量去谈性质的问题。这种通过技术手段违反行政规定的事，一抓一个准。而被抓起来之后，除非能证明行政规定本身无效外，无补偿被开除是最低的惩罚。

如果真得不是什么重要数据，那么让 DBA 直接开个限制权限的账户，不但更安全，还更好用。

@imyasON #9 碰见这种需求，我只能祝福你。

用了企业微信，但是不用企业微信的考勤，是出于什么考虑。企业微信的考勤就是带人脸识别的。

楼主：行就是行，不行就不行。
回答的人：不行。
楼主：不能不行。
回答的人：行吧。
楼主，转向其他人提问：为什么有的人那么喜欢说“行吧”。行就是行，不行就不行。

这是多么经典的场景

@worldqiuzhi #12

如果只是个无意义的代码，那就不用编码，直接用名称。对于名称的变更，还有范围（对应前端的下拉/单选/复选的选项），另行准备其他数据模型去管理（请注意，相比与数据字典方式，这并没有增加工作量）。

如果是完整数据的名称属性，例如部门的部门名称、商品的商品名称，那么需要分两种情况考虑。如果需要的是历史名称，例如订单上的商品名称，那么直接将名称固化的主数据上。如果需要的是当前名称，例如员工的部门名称，那么就只能根据主键去关联了。当然，这时候在面向前端时，如何写代码以及如何控制性能，跟数据字典一样的复杂。像部门这种少的数据还可以直接全量放到缓存上，如果数据量很大，那还得回落到数据字典方式，不过这时候是（自然/代理）主键——名称的字典，不是编码——名称的字典。

编码——名称这种存储方式，以前肯定有其有利的地方。但现在，在存储成本可以忽略的时候，再搞编码，对业务逻辑、UI 、大小数据统计，都是负影响。

更正一下，不是烂设计，是真特么已经不符合当下的过期设计。

你需要一个专门的数据字典模块/服务，供前后端同时使用（大部分时间是后端在用，显示时候的转码映射要后端做，前端仅在下拉框等动态内容获取时才使用）。还需要重新规划数据模型，将字典数据全部提取到一起，交给数据字典模块去负责。这还不算完，后端得调整架构，以尽量减少数据字典映射代码。前端需要合理设计缓存以减少网络响应时间。

数据字典，或者说编码-名称模型，真特么是一个烂设计。

看楼上的回复这还是通用 TOTP 方式，有条件开就开了吧。避免将来哪天被明面上以用户安全为理由，实际上是把你当作机器人帐号，让你要么交出手机号要么放弃帐号。我的谷歌小号已经因为上面场景全丢了。Vavle 刚刚以安全为理由，要所有开发者交出手机号。

@shervy #12 先看看楼主的连接数，100-200 ，这个量级，xshell 这个贵物是用不起的。

一般都是不管，因为存储成本真得很低。

我的预想方案如下。把所有附件，先转换成「资源」表的一个记录。资源表负责存储附件的相对路径，外部只能通过资源 ID 去关联附件。然后你就可以在资源表中维护附件的状态、关联性等，以及延时或者定期清理没有外部关联的资源记录和其对应的文件。因为「资源」个数据库表，它可以跟主业务保持事务一致性。资源表跟附件本身的一致性则需要额外保证，一般也只是保证从资源表到附件的单向一致性——只需要先保存文件再插数据，同时禁止外部删除文件即可。如果需要保证资源表跟附件的完全一致性，那开发成本将非常高。此方案仅存在与预想，因为参与过的老项目压根不会改，新项目涉及到开发时间就连我自己都不会上这种方案。