有挂 waf 吗，现在一个小网站/博客都没几个活人看，却被几百个 bot 轮番轰炸

卡多少？最近似乎普遍卡 30%。

@CodeCodeStudy #4 包的数量不能说明什么
https://i.imgur.com/u2Fpju7.png
https://i.imgur.com/7UAPRuL.png
上面甚至有一行代码都没有的包
https://mooncakes.io/docs/CAIMEOX/%E5%8E%9F%E6%9D%A5%E5%8F%AF%E4%BB%A5%E5%8F%91%E4%B8%AD%E6%96%87%E5%8C%85
http://archive.today/R4yCc

@hzzhzzdogee #82 gpt-5-high 还是目前最能打的，sonnet4.5 ≈ glm4.6 ，但 glm4.6 便宜

@1nav #11 robotjs 21 年停止更新之后的 nut.js 算是替代品，不过 24 年转闭源收费，不想花钱最后开源版本够用了。还有个小众的 keysender 可以尝试下。
另外如果想要直接操作软件，可以试试 playwright 操作 electron 或 webview2

Rust 青春版，编译器未开源。
目前看起来对比 TypeScript 没有任何竞争力。
看了下这是你发的第 21 个 MoonBit 贴了，这个推广太生硬了 /go/promotions

@TimG 好经典的欧亨利式转折

程序员必须要折腾下 nas ，哪怕用不到扔角落吃灰🤣

nodejs 最方便，某一天我把所有.py 重构成了.ts

@iseki #38 A 持有 B 的引用且能修改，是 OOP 的罪恶根源，标准库基本都是无状态/不可变对象(除了和 java 互操作的可变对象)，但最下游的消费者还是应该尽量多用函数式。
对一些全局变量，我的通常做法是设为私有顶级成员，相比 companion object 少写 3 行。(FP 致力于消除一切全局可变变量，理论上都是"错误"用法)。
interface implements extends 是类型约束的一部分，kotlin 作为多范式语言提供了更多的可选组合，例如用 object 委托实现适配一些接口，或者用函数类型+高阶函数进行限定(实现接口本质是提供一个符合签名的函数)。多范式语言提倡组合优于继承(委托、扩展函数)，函数一等公民(顶层函数、高阶函数、闭包)，使用语言提供的单元(module/package/.kt)而非 interface/class/object 组织代码就变成很自然的事，真要用接口也尽量用 SAM 。
写 kt 我一般还是建议不要太沉迷 OOP 的特性，多提升 FP 含量，少点过度抽象少写点代码。
https://www.reddit.com/r/Kotlin/comments/kziv7e/a_closure_is_a_poor_mans_object/

@iseki #32 确实如此，虽然多范式语言并不关心这点。singleton (单例) 与 monostate (单态) 都是编程语言在不支持顶层作用域函数/变量的情况下管理全局函数/变量的方案，缺点都差不多，相比之下单态更加差劲。
https://wiki.c2.com/?MonostatePattern
以 kt 举例，顶层 object 基本都被用成了 namespace ，我很少见到把它当单例用的。

@iseki #27 这个单例或许加个引号更合适，确实不是"例"，一时也想不出更贴切的名词，本质上都是全局变量的唯一访问点。部分语言提出单例概念是因为变量必须放在 class 内，因此催生了一个绕过方法。假如语言支持在 class 外也有作用域，那么全局变量的载体不一定要是对象，js 可以是 module ，go 可以是 package ，也没必要实例化了，它们是语言级别的特殊对象，也能实现对象的特性(一次初始化、修饰符、延迟加载)，而二者的具体差异可以忽略不计(例如静态内存 vs 动态内存)。
写 Java 的也从来不会用单例，用的是依赖注入默认情况下表现出来的单例特性，这其实也不是单例。

开源 !== 优秀
开源 !== 能用
开源 !== 够用
大多数软件是个人程序员+社区互帮互助的产物，不要问为什么没有 xxx Linux 版本，真的需要应该自己动手移植或者重写，没人做说明它不具备诞生的必要条件。

自定义迭代器主要有几个场景，一是修改可迭代数据的行为，例如将有序列表对象以乱序读取，例如给一个 gif 抽帧；二是给不可迭代数据添加一个迭代行为，例如可以把一棵树以某种策略输出为扁平化列表；三是迭代行为与其他逻辑紧密相连，例如读取文件信息、写入数据、关闭资源，下一个文件的选择、处理方式与上一个有关，这么一坨东西可以放迭代器里。
对外部模块来说，这一部分复杂度就转移进迭代器里了，它不用关心多余逻辑，只管 for 就行了，本质上是抽象与组织代码的权衡。

相比生成器，迭代器的优势场景在于：
1. 维护复杂的内部状态管理，简单依靠恢复/暂停不好实现，例如要维护一个状态机。
2. 要公开某些状态给外部，例如公开进度条、统计信息。
3. 行为逻辑更加 OOP ，如果你的 Python 代码充满了 OOP 的味道会更合适。
其余情况还是用生成器更好。

当然，并非一定要用迭代器/生成器实现，完全不使用也照样能做，取决于个人习惯。你说实际应用中没看过自定义的迭代器，非常正常，因为该程序员不希望把逻辑放进迭代器的内部，这本质上是垃圾放一楼还是二楼的问题，其实没有区别。编写代码有 114514 种抽象方法，你不用 xxx 代码照写世界照常运转并没什么影响，唯一影响是你没尝试过不能切身判断它到底好不好，适不适合你或者你的代码。

@slowman #7 前男友不是前夫啊，还是一婚还能卖个好价。

@wogogoing #8 哪里有问题？
Go 保证一个 package 只会初始化一次，包内的变量是包级作用域的全局变量，全局唯一，这不就是天生的单例。
扩展阅读： https://stackoverflow.com/questions/1823286/singleton-in-go
`Just put your variables and functions at the package level.`
这能够解决 99%使用场景，如果无法解决，参考排名第一的回答。

如果这两年没折腾过 AI ，那寄得很彻底了

我对设计模式的理解
单例模式：部分落后的面向对象语言特有的反模式，违反单一原则，一个类不仅要实现功能，还需要管理自己的唯一实例。Java 中已由 SpringBoot 解决了底层的垃圾活，如果需要自行实现单例我只会觉得这人的脑袋坏掉了。
大部分情况出自 Java 面试题，经典且无用的八股文，仅仅为了考察根本用不到的懒加载、指令重排。
对于更先进的面向对象语言很好解决，例如 kotlin 的 object ，js 的{}，跳过 class 这一步直接创造对象就行了。
至于 Go 呢，package 是单例，sync.Once 可以实现延迟加载。

工厂、建造者、原型模式：Java 有用的设计理念，但是 Go 没有继承/重载，只能写点似是而非的东西。
但作为面试题，这三个只比单例好一点，也几乎没有实际意义。

代理、装饰器模式：由于 SpringBoot ，在 Java 里它们是基础设施，是面试题应该重点考的东西，可以避免一些错误的使用方法。

适配器模式：非常好的理念，编程是在破旧的茅草屋上缝缝补补，拆东墙补西墙，适配器让各种屎山能成功运转起来，是一座丰碑。

很多设计模式我只在自己的玩具项目上尝试引入，确实有些是很好的理念，但工作中我不会自找麻烦。设计模式要为代码实现服务，如果使用了设计模式能少写代码，好写代码，那么是好的，可惜事实并非如此，绝大部分业务/场景的复杂度远达不到 Springboot 框架的程度，强行引入一个又一个设计模式不如去干点更有意义的事。

例如可以折腾下多平台聊天机器人之类的玩具，真心要写得好这些设计模式几乎都会用到。
正常的话是不应该过度使用设计模式的，Java 还好说，Go 去凑合设计模式是没苦硬吃。
如果真的对设计模式情有独钟，就多写点呗，23 种设计模式已经是三十年前的破烂了，要与时俱进挑战一下 62 种：
https://github.com/iluwatar/java-design-patterns

json 你要考虑这几个问题：
1. 数据竟态，多个进程修改同一个文件互相覆盖，极端情况下文件可能会损坏
2. 序列化/IO 开销大，改动 1 个字符也要重新全部读取->序列化->修改->反序列化->全部写入
3. 如果选择常驻内存模式不会有上述问题，但是新增了磁盘保存问题，应用意外退出会丢失数据
当你解决完所有问题，恭喜你再次发明了 sqlite