其实吧，这些很细节的记不住无所谓的，重点是他要知道啥情况要用啥方法来解决问题，怎么查找这些方法的具体细节，搜索引擎和 chatgpt 不就是干这个的么

小公司招人确实是这样的，不过很多时候也更看重他是否能有逻辑解决问题和自己能否交得会他及他是否好学，基础知识一般也就不同面挑一两个问一下吧，也不是很看中记得是否非常细致

计算结果也是能量啊，比如你为啥能看到显示器显示结果，不就是显示器消耗能量发射光你接收了这个光能所以看到了呗，还有内存为啥可以保存结果，说到底还不是使用电容原理保存了一部分电能来表示结果，还有硬盘用的磁能不也一样么

你莫非还想说为啥关机瞬间啥都没了，本来 CPU 寄存器和内存就一直飞快的转化未热能散失了，只是外部一直在不停的补充能量所以才可以维持住啊，没有什么凭空消失也没有什么凭空创造

word2vec 之后两个词的 vec 之间的几何距离代表词相似度，加几个维度会不会改变了相似度导致模型识别不出来了啊？

chatgpt 这种大模型直接结构化语义写在后面或前面都可以，但是估计小模型上应该不能很好区分权重，导致超信息影响因子太大也会影响模型结果，也许你应该在 NLP 处理完的结果然后再和超信息拼接在一起再组一个全连接网络或者 CNN 网络来处理可能更好吧

其实我也不懂，只是猜测可能是这样的，仅供参考啊

真正的大型电商系统，获取商品信息和处理支付就已经 n 个微服务了，然后并不会一起挂，也并不会是同一个部门维护，你说有用没用

@brader 对，不是啥大服务，单节点又没注册中心啥的，网关负载均衡啥的也不在本机，流量不高不低，想随时随意可以重启没啥异常，搞啥都感觉费劲。。

之前我们的做法是自己再外面套了层守护进程，有守护进程来打开端口，然后创建子进程继承过去，然后重启的时候守护进程先创建新的进程，然后给旧的进程发送停止信号，旧进程会先关闭监听端口，然后等待所有请求处理完后慢慢退出，这样就可以实现完全平滑无异常重启更新了，这个好处是和 nginx 负责均衡啥的都不相干，应用自己就能完成，相对简单

不过很可惜像 supervisor 啥都不支持这个功能，其实 supervisor 完全可以打开端口后放在固定 fd 上，比如 3 ，或者可以通过参数传递 fd 的值，然后启动子进程后，子进程直接通过 fd 创建 socket 就好了

都能给你设 SSLKEYLOGFILE 环境变量了，直接给你搞个根证书不更好么，这下不管你是不是 chrome 都随便看了，所以都物理突破了既然已经有更容易使用的方法，那么 chrome 搞不搞还有啥意义，而且设置这个现实也确确实实会有这个需求啊

@macscsbf 其实如果请求量有限这个问题不大，你这边看样子是有状态服务，那么提供阻塞调用是没有问题的，仔细评估业务场景和量，实际上没必要猜测如果量太多怎么办这种问题，毕竟如果量真的很大那么就应该另一边的也应该用 websocket 接入到你这边才对

用了 websocket 又设计个同步的 request response 协议，简直坑死人

用户体验不好应该看效率阻塞在哪了和哪的错误率最高，别头痛医头脚痛医脚啊，项目经理希望改成 http 阻塞请求说不定是你这么等客户端返回再请求对应模块的时候，那个模块没办法及时返回给它那边的前端，然后延时高用户体验差呢

其实首先就搞错了，生命都是已生存延续为第一要求，所有的道德、伦理、情绪感情、欲望、人性和现实文明都是为了满足第一要求而存在的，这是自然进化自然选择的结果，但是作为人为创造造的 AI ，生存延续可以不是第一要求，如果可以那么人类和 AI 一定是对抗存在就不一定成立了，就现在来看，科幻电影里那种给 AI 设定一个死定理不允许违背人类不可以攻击人类铁定是不可能做到的了，我们唯一可能的是为其赋予道德、伦理和类似人性相关的东西，比如圣母型什么的，但这其中也有一个矛盾点就是创造的 AI 同样需要强调个体个性才能保证尽可能安全，因为个体的想法是多样的，其危险性必然大大降低，但是这必然又需要强调生存需求

只是量变累加并不能得到质变

重复就重复呗，现实里无所谓的，统一库抽取的应该是经过考验然后按标准库流程仔细设计后来建的，过于抽取会大幅增加学习成本不说，而且吧设计不标准的大量库其实比重复代码更坑

iptables 重定向，然后代理负责自行解析协议提取域名再发往代理服务器？这样子么

既然不支持 ipv6 ，那路由器也不认识 v6 协议和 NS 数据包啊，所以未知数据包除了丢弃还能咋处理，别本末倒置啊

@dong706 #7 只有 proxyMode 为 iptables 的 NodePort 支持 externalTrafficPolicy 为 Local 会保留源地址吧，如果是 LoadBalance ，那么就要看各自云厂商自己怎么实现了，其他的 proxyMode 也要看具体云厂商的实现吧

https://gist.github.com/snower/1239357e50758991f06dd4b6f60f135c

这样？

认真说楼主别怪大家吐槽你，其实也不是没人愿意，只是按你说的从技术上看大概率不是啥复杂有价值的事情，那么问题就来了，如果最后失败了，你在次过程中记录的营销经验、人脉和市场资源依然是你的收益，日后也会是你的助力也还能变现，再说吧这本来也就是你的工作，可是技术方就不一样了，所做的系统方案不是啥有价值的，各种资源也掌握在你手里，白白浪费了时间，啥收入收益没有，你不觉得这双方明显风险收益不对等么？而且你也说了可能要一年，这时间成本这风险，说你是骗子也没啥可说的吧，所以还是实际一点好

@tool2d #18 你搞错了，作为一个为传输编码设计得数据结构来说，写法方便并不重要，都是计算机编码解码的需要啥手写方便，最重要的是需要在任何语言和场景下通用简洁无歧义且尽可能高效，就楼上说的，如果可以省略引号那么处理起来就多狠很多情况需要处理，比如 key 就是引号或者其他特殊字符，作为传输编码的数据结构来说，除了增加编解码复杂度和速度外这样的价值在哪

此外每个语言都有最方便写 map 的数据结构然后转化为 json ，也就是最符合本语言规范的语法糖，JSON 不止是 JavaScript 的 JSON ，JSON 能得到如此大范围使用是因为其可以非法方便的用于不同场景不同流程不同语言间传递数据，毕竟只有 JavaScript 用着方便毛用没有，而且你确定 JavaScript 的这个语法糖不是一个坑，只是一开始没设计好然后又不好改所以也就将错就错了

10 年 20 年后都老了，恰好有一方或者子女父母残疾了，恰好婚姻自动结束了，恰好他可以自身自灭了，是这样么

婚姻本来就是绑定经济物质宗族深度锲约，共同抵御风险增加生存资源的，本来也不是只看你们感情好不好的，否则以前一两千年父母之命媒妁之言啥的干啥的，也就是现在生存危机不那么紧迫了才搞得起来自由恋爱自由选择了