跟规模没关系吧，我家用服务器也用 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 回家，用了一两年也没见有什么问题

AI 不太适合你不懂的领域，问的不好，很容易被坑然后绕进去。更适合你懂一点但是不是特别懂的领域，多反问就不会太容易被误导。找到一个适合自己使用边界很重要。

nas 小主机性能不行，直接 pc 机 windows 挂盘组存储池，也不影响正常用

这种场景常会依赖海量数据，比如去分析某个大型社交网络上用户实体之间的关系，生成用户画像，就可以基于图数据库构建知识图谱。

ceph 其实没你想得那么复杂，而且可以统一存储底层，cephadm 现在部署很简单，默认引导完添加一下 osd 集群就部署好了，而且自带 orch 编排，配合 systemd + podman 管理也没那么复杂，只需要用 rgw 对象存储的话，rbd 块存储 和 cephfs 文件存储你不配置保持默认都行，另外 ceph 是前期规划复杂点，后面稳定了基本不怎么要维护，只要挂盘扩容就行了。