@olaloong #82 学到了，先做成模块混淆，然后写回工程里

要是做解决方案类型的那种展示页，肯定是 SSR 更合适；涉及到文档比如产品说明、部署手册，单独弄个工程做 SSG 。

阿里的东西，我只会白嫖，不会多花一毛

想在 vm 里也支持透明代理，还是在 linux 或者路由器层面解决更合适，或者找一个 windows 11 上能代替 iptables 的软件将流量重定向到 tun ，用 vmware NAT 虽然能解决问题，个人觉得 vmware 还是桥接用起来舒服，其实配置 http_proxy 也简单的吧。

跟规模没关系吧，我家用服务器也用 K8s

AI 多力量大是吧

你能读懂 AI 的代码，那你说个几倍不过分，你看起来吃力甚至不理解，那后面维护的时候就有你受的了

没太大意义了，跟 AI 说具体场景，给出输入输出规则，让他给算法模块就行了，比你自己研究半天搞出来的好得多。

国内外技术差距没那么大，差的是数据

今天 gemini 就给我整无语了，问了一个 K8s odic 命令行工具的问题，我都已经把 -help 的完整信息发给它了。它还是总会给我自作聪明的添加一些不存在参数，我质问了有数 10 次，然后它道歉了数 10 次，吹捧能力一流，道歉能力一流。

@twk93 #4 不可能吧，估计是你看错了，谷歌推荐的验证方式首选 HTML 文件，如果你使用 hugo 这种框架建站，一般使用 HTML 标签是最方便的。

用 HTML 标签验证不行吗，不是有好几种方法吗？

无所谓，早就转 VSCode 了，Java 也不怎么用了

淘宝也是这样的，搞个优惠活动一大堆规则，又想忽悠用户来买，又怕被人薅羊毛，还不如一口价折扣来的实在

从你第一句开始，我大概能猜到，你大概率是用错了。
比如你有一个复杂的表单查询 API ，你通常并不需要去写单元测试去测这个 API ，去模拟各种参数传入调用 API ，这没有必要，这种场景通常用 postman 、jmeter 这类工具去做就可以了。
单元测试通常是测 API 内部的业务逻辑，也就是针对模块化出来的代码单元去进行测试，当然并不是每个业务逻辑都需要测，涉及非常复杂的业务，你也可以先写单元测试，再写具体的代码逻辑。

@kyonn #12 负载均衡，不过通常很少直接在 compose 里用 scale ，会集成 swarm 或者用 k8s 来实现

因为 docker compose 本来就更适合于单机场景，通常一个 compose 文件一个网段，此时 service_name 是唯一的，不存在冲突。

```bash
networks:
net:
driver: bridge
external: false
ipam:
config:
- subnet: 172.19.0.0/24
...
...
```

如果你不指定 container_name ，通常会加上 project_name 前缀，和 index 后缀，swarm 也类似，用户完全不需要关心 container_name ，swarm 随机生成。

至于为什么不建议指定 container_name ，主要是不利于 scale ，非常不灵活。话说回来，有 scale 需求的，一般都上 K8s 了。

事实上，富人的小孩也学习，学的还比穷人好

开 22 端口，无密码登录，没事就 ssh 回家，用了一两年也没见有什么问题