我对设计模式的理解
单例模式：部分落后的面向对象语言特有的反模式，违反单一原则，一个类不仅要实现功能，还需要管理自己的唯一实例。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

无法正常读写那肯定不行了，你连完全格式化都做不到，更不要说全盘加密。
如果用物理手段破坏数据，无法享受保修。

外包常用话术
你现在做了外包，下次换工作大概率也只能继续外包
大公司背调基本不会要有外包经验的，除非能力真的非常优秀(话说回来，这种人不会沦落到做外包)
接着找吧

@DefoliationM #14 拿 rust 写 web 是认真的吗，我也经常写 rust ，我认为 rust 写 web 是自讨苦吃，ts 或 c# 不好吗

@DefoliationM #20 他指的是 kt 原生没多少岗位， 这确实是现实情况，学了 kotlin 想找份客户端实习对现在的环境来说是地狱难度。

@maymay5 #1 /t/1164407
早就不让切了
老用户等下个周期会按新计费模式算

你同事看到这贴绝对笑坏了哈哈哈哈
赶紧 remake 吧，小心别因为注册日期再被抓了

看到评论里的 Minor releases 笑出声
3.14.1,
3.14.15,
3.14.159,
3.14.1592,
3.14.15926,
……
相关改动在一年之前就合并了，还提前修复了这个彩蛋可能产生的破坏性行为，虽然还是可能会给 3.15 埋下一些雷

字符串是相对最好的处理方法，推特碰上这个坑也是这么做的，有更好的方法早用了。

@chaoz611 我国庆在应用商店里下载下来就是这样

我这里疫情前一平方 4 万，现在 3 万不到，在房产中介工作的亲戚说挂单一堆，但是买的没几个。
房价在以前是高于 70 年房租，现在只是跌回了 70 年房租的正常价格，泡沫般的附加价值已经没人接受了。
大多数普通上班族本就没必要买房，老实租房就行，高价背贷款买的，往后可是要花 10-20 年的持续努力，很多人并看不到风险与压力，只是观念里一定要有个房。
至于炒房的，炒输了活几把该。

车险是包赔的，流程清晰定责明确，该赔多少就是多少，简单直接。
人险先过文字游戏那关，大部分保险我只能用"阴险"两字来形容，拿到赔偿真的很难，扯皮耗死你。

抖音之类的平台真是害人不浅，我妈也是会买一些莫名其妙的东西。

@ohoh #22 农村的地有什么用，要拿回来还得放弃城市户口。20W 平摊给 10 年生活费每天有 55 块呢，够一大家子生活了，为了面子扔这 20W 我是舍不得。

不就是赶潮流做个 AI 短片吗，军费没地方花又在整烂活了。

那些头像比 AI 早很久，花点小钱找设计师呗，现在用 AI 就行了

这要结合具体上下文来看，有时候恰当的例子可能不如不恰当的例子更容易理解，特别是大部分观众没接触过的专业性问题。为什么不举恰当的例子，大部分时候是怕你听不懂。