顺便说如果你担心他这样会养成只要想要就一定要得到之类的性格，但感觉就他这个年龄这个担心纯属多余了吧，且不说可以等他再大一点可以通过教育学习改善，而且就现实来说，他第一意识是想要的东西一定要得到，那绝对会有一堆人来告诉他痴心妄想，但是如果第一意识是想要的肯定不行，那可没有人会推着他去尝试，不踩他一脚就是善良的人了，所以前者且不说在现在这个社会更有利，而且在后天的教育生活学习中通过现实的负反馈更容易达成平衡而形成更好性格，但反过来却是更容易得到更糟糕的正反馈而变得更糟糕

再说点可能不那么准确的东西，人类作为幼体过于弱小的群体，进化基因里必然是社会话动物的，那么 3 岁以前大概率就是基因激活环境验证的阶段，以获取更好的环境适应来增加延续性，如果你这时候过于克制他的需求，说不好更多激活的就是哪些不符合社会化的规则，也许长大了其思维方式和潜意识逻辑会对社会化规则比较原理，可能对现代高度发达的现代化社会适应能力和发展能力就会弱很多，就算后期通过教育有所改善还是太难了，个人亲身经历感觉就是这样的

@JungleZZ #56 说个反例吧，我是属于你想的那种特别小时候大人忙怎么哭不怎么管的，虽然 3 岁以前的记忆几乎没有，但是潜意识仍然形成了些非常不好的东西，即使长大了还是非常受很大影响，所以你都说了他还那么小还只会说爸爸妈妈，依赖你有要求就有会应太正常了吧，都不说是刻在基因里的东西，等他会完整说话会走会跑了真的是一个独立的人了再叫他独立性和克制也不迟吧，他这年纪还不会有完整记忆也正因此刻在潜意识里才可怕，潜意识的不安全感什么的都是轻的

v6 开启 nat 支持配置端口转发也只能转发到 v6 内网地址吧

不需要这么费劲吧，常用的库比如 okhttp 都支持设置自定义证书验证回调吧，在回调里处理下直接忽略证书过期然后改成直接验证服务器证书指纹就好了啊，也是安全的

import okhttp3.*;
import javax.net.ssl.*;
import java.security.cert.X509Certificate;

public class CustomVerifyOkHttp {

public static OkHttpClient buildClient() throws Exception {
TrustManager[] trustManagers = new TrustManager[]{
new X509TrustManager() {
@Override
public void checkClientTrusted(X509Certificate[] chain, String authType) {
// 不处理客户端
}

@Override
public void checkServerTrusted(X509Certificate[] chain, String authType)
throws CertificateException {
// 示例：只信任特定公钥指纹
X509Certificate cert = chain[0];
String sha256 = sha256(cert.getPublicKey().getEncoded());
if (!"your_expected_sha256_fingerprint".equalsIgnoreCase(sha256)) {
throw new CertificateException("Untrusted server certificate");
}
}

@Override
public X509Certificate[] getAcceptedIssuers() {
return new X509Certificate[0];
}
}
};

SSLContext sslCOntext= SSLContext.getInstance("TLS");
sslContext.init(null, trustManagers, new java.security.SecureRandom());

return new OkHttpClient.Builder()
.sslSocketFactory(sslContext.getSocketFactory(), (X509TrustManager) trustManagers[0])
.hostnameVerifier((hostname, session) -> true) // 可选：略过主机名验证
.build();
}

private static String sha256(byte[] data) throws Exception {
java.security.MessageDigest md = java.security.MessageDigest.getInstance("SHA-256");
byte[] digest = md.digest(data);
StringBuilder sb = new StringBuilder();
for (byte b : digest) sb.append(String.format("%02x", b));
return sb.toString();
}
}


基本就是这样，这样之后楼上说的什么中间人抓包也没可能了

国产化系统基本上内核、标准库、编译器都很老了，这些货一个一个都完全没计划考虑定期升级个内核什么的，真是坑死个人的

@magic3584 #15 C++代码也是架构和系统绑定的啊，首先动态链接库 windows 叫 dll ，国产底层都是 linux 叫 so ，就算你有源码都不一定能在过程系统上编译出 so 来，这还有工具链、编译器版本和标准库依赖的问题，没源码的话就歇了吧

C#代码就算迁移到.net core 如果不是 asp.net 那一套估计工作量感觉还行，否则几乎等同于重写了吧

不搞个生成二维码

@dorothyREN #1 而且遇到不存在的配置文件查询也立即返回文件已修改，这似乎也不合理吧

@dorothyREN #1 这东西也没啥权限可以设置，用不用的感觉也没啥区别吧，如果只是小团队用估计也没啥必要还去分啥 namespace 吧，但是有这问题就不合理了

我们用的是 proxifier ，proxifier 配规则拦截掉全部对 pod 的 ip 访问，然后在 k8s 里用 deployment 部署一个简单的 socks5 代理来负责转发，安装配置简单，开发过程也是无感的

顺便说如果你用的是大家用挺多的 redis 分布式锁，因为 redis 协议原因，冲突率较高情况下性能会有较大下降，单个加锁延时在冲突率高情况下提高不少，也是需要考虑的
一般来说各种介绍分布式锁使用的文章说到的场景实际冲突率都低于百分之一吧，可以统计或者预估下冲突率在啥价格
如果冲突率实在高又并发不均衡就是有较大峰值，那还是好好的用 kafka 来搞吧

看了半天似乎你这个不就是某个人开始结束时间更新不应该因为时序和并发问题覆盖回跳吧，不用那么纠结按人加锁就是了吧，我看你补充说可能操作的时候不上报结束统一上报，但也就是几百个而已
加锁要分析的是冲突率、单操作耗时和等待时长，然后以此计算线程连接各种资源是否能满足需要的并发，不是加锁就不能高并发吧
就你这也就计算更新个时间耗时这么低，按人加锁也没多大影响吧

你这第一条客户端校验服务端证书就理解不对吧，证书校验就是验证 ca 是否合法，只不过一般的 https 客户端默认使用一堆系统内置的可信 ca 来校验，任意通过即可，所以外加域名验证来确认服务器签发的证书是有效，但是客户端这个行为也是可配置的，如果你指定只信任特定 ca ，而这个 ca 签发服务器证书是有你控制的那就没必要校验域名了啊
而服务器这边开启客户端校验的时候默认行为就是需要添加需要信任的指定 ca 的吧，而且这个 ca 签发客户端证书也是你可控的，这不就好了，虽然这个行为也是可配置调整的，既然你都调整配置了，那你也完全可以指定继续校验客户端证书的其他信息啊，比如指定特定指纹才是有效的

@Greendays #39 为了在游戏里作弊不能，但是为了在游戏里帮别人作弊赚钱可以，23333

@linxuan716 #12 还好吧，阿里云之类镜像服务都有自动化服务吧，授权仓库绑定建 tab 就自定 build ，镜像仓库在设置好触发器自动触发 k8s 更新滚动重启，这不比你拉代码重启还简单

主要问题是业务量不够上了 k8s 会贵不少，维护哪复杂了，更简单了吧

@happydezhangning 显然不能，三个三峡而已，对我国现在的用电量来说也就几分之一，影响电价显然完全没可能，如果把太阳能板铺满罗布泊那发电量那倒是可能了，想达到影响电价年发电量怎么也得有个 3 万亿度还差不多，这可是十几个三峡才能提供的年发电量啊