没有价保吗，要不问问客服？

1. KOOK ，但是好像收费
2. 自建 ffmpeg+obs ，但是延迟好像有点高
3. 腾讯会议，不知道分享游戏时的帧数行不行，应该不大行

现在还有在产 500g 的机械吗，不了解这个行业，但是京东上并没有看到自营在卖，反正感觉这个需求很特别

我不是很懂你说的风险指的是什么，因为不懂所以担心不能正常交付吗？

很少有看到完全的上位替代品吧，只能说市场份额大幅度缩水
比如 Memcached
swing ，jsf 这些才真叫落伍，还有 Struts

说到前端，变化太快，可能你刚接触某个库，再深入了解一点就发现它在几个月前已经不更新了，被 out 了

我觉得你可以先明确你当前的目标，计算机属于工学，但内部细分其实也分工学理学
你目前的困惑在于这二者的区别，理学是对理论的研究，是科研，工学更多的是对理学的落地，是过程是结果

除非是天才，一般人在这二者之中基本只能选择其一，这当然并不是说你做工程就不能出科研结果，做科研就做不出落地的项目，这其实有关你对事物的看法和行为方式。
现实中有很多工程学天才，他们可以轻易的将抽象的理论应用与实际，开发出优秀的作品。也有理学天才总是能迸发出创新的火花。更有很多人，他其实是工学思维但走上了理学的道路，这其实会让他痛苦无比。

学校显然属于一个理论先于工程的环境，不知道你们学校有没有金工实训的课程，让你用尺规画图画一个五角星，这很简单，但让你用锉刀锉一个出来你现在可能就束手无策，让你为工人设计一个批量加工的方案更显得为难，这在于理论是确定的，但是工程却会因为外部环境变化而变化。因此学校更注重理论的传授，这也更直接有效。

回到开始，对于计算机相关专业来说，学校的内容肯定是不够的，但对比其他工学学科来说，我觉得计算机有一个宝库——开源。
现阶段我觉得你应该找到自己的兴趣点或者以你看待问题的方式，你是愿意科研还是将理论应用于实际（再强调下这两者并不冲突，这只是让你更舒服）。选择一条适合的道路，我相信你现在已经领先大多数同龄人了。加油！

吾生也有涯，而知也无涯，以有涯随无涯，殆己！

主题 5 分钟内可以编辑的
我觉得 godot 好，但这是一个外行的感受

/t/984299
前两天不是就有帖子讨论过了吗，这个帖子还能回答为啥不能像你这样写

过个生就送 ipad 的吗，v 站的生活水平果然是高啊
喜欢阅读可以送两本好书，喜欢运动可以送跑鞋，喜欢听歌可以送耳机，喜欢游戏送一套桌游
举几个例子参考

server {
server_name a.com;
listen 80;
location / {
proxy_pass xxxxx;
}
}
server {
server_name b.com;
listen 80;
location / {
proxy_pass xxxxx;
}
}


这样配置

找个内胆好的，不沾米不掉涂层，方便清洗的就行吧

全局的常量字典我选择直接返回 code/id ，前端页面中会先查询所有这个类型字典的数据，所以能自行显示对应名称。这种通常用于如：产品类型，状态等字段。

你说的这个属于业务型的关联查询。就 left join 查就可以了吧，如果由于整个 sql 关联了很多表且其中有大表导致查询比较慢，可以选择在代码中单独将零件的名称查出来再赋值，必要时使用缓存。

我通常也不愿意写很长的 sql ，sql 越长越容易出问题，且通常说明设计不太合理。但也要实际情况结合来看，没有绝对的对错

> 云服务器 4 核 8G5M 带宽 373/年

怎么没看到这个

spec.nodeName

https://kubernetes.io/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#use-pod-fields-as-values-for-environment-variables

然后在 yaml 里就可以直接使用环境变量了，你可以试下，一个集群才适合这种，你是三个集群那这 3 个 node 的名称可能是一样的。

3 个集群的话直接 configmap 配置个环境变量不就好了吗，不让改 k8s 里配置的 yaml ，添加一个总没问题吧

先判断老板意图，
问老板是觉得现在哪里不满意呢？
如果老板啥都说不出来，那就如楼上所说，在钓鱼，你就说现在都挺好的
如果老板有说哪些地方，你就顺着说
总之把问题再抛回给老板，这就叫打太极

同失业中，工作太难找了

> 简单的映射、移位、异或、置换
这种方式和古典密码学一样，特征太明显了

从需求出发，我觉得你的算法只要满足你现在的需求就能用，毕竟你又不给别人用

从算法讨论出发
1. 我觉得 1 楼说的对
2. 永远不要自己设计使用加密算法
3. 安全在于密钥而不在算法

> 同样也没见过多少人真的拿用户 id 上 AES 的
感觉就没多少场景有和你这个类似的需求的，通常来说 id 本来就不是什么敏感数据，暴露一个 id 和一个 hash 或加密后的 id 根本没多少区别，特别是现在大规模使用 uuid ，雪花 id 的情况下。
担心伪造 id 应该通过数据权限控制，担心暴力刷接口应该用其他安全机制