主要中西医这个说法就有问题，与其说是西医不如更确切说是现代医学。

中医作为传统医学肯定有一定价值，一些经验药方药理作为线索进行系统性医学研究、实验，是能够带来不错的成果的（屠呦呦）。

但中医很多理论不可证伪，和玄学一样这里面操作空间可太大了，而且明确中国整个体制系统内有很多相关产业的既得利益者，这其实是一定程度阻碍了中国现代医学以及产业的发展的。

记得当时上海新冠封城的时候，小区叫出门拿救助，还以为领吃的，结果领了好几盒莲花清瘟，那时候我觉得他妈的有些天龙人是真的牛逼。

可以做，看做 ToC 还是 ToB ，其实 ToB 养活自己的小公司很多，但你的客户关系从哪里反而是更重要的事情，以及其实利润也不高

麻将也是 pvp 呀，雀魂啥的。
不玩钱，心态放平，打发时间

但整体上对我这种前端非熟练工来说是有数倍的效率提升的，差不多半小时~一小时一个页面这样

@MackMa 我也经常用 Figma MCP
基本上现在 UI 给我原型我都一个一个组件让 Cursor 去写，然后再微调下。
一般来说好的效果需要设计师对于切片图层有好的结构组织
以及 Figma MCP 对于 Figma 里的动画效果解析很差，现在我基本还是得自己分析关键帧手撸

已转，最近行业里很关注这个。

能理解 OP 的观点，但选择如何生活其实是件很私人的事情。
抚养孩子这事情吊诡的地方在于，他的高昂成本以及对生活质量的影响显而易见，而很多正反馈（如情绪价值）以及回报都是长期且隐性的，很难为外人所知，而且很多养孩子的人也不一定能从中获得这样的正反馈。

儿子明年要三岁了，明年我也要准备扮圣诞老人了。

问我的话，我其实一点也不关心别人是怎么活着的，只要不违背普世的价值观与道德，然后不影响到我都 OK 。
身边朋友不结婚的、丁克的、性取向不同的都大有人在，每个人选择自己觉得合适的生活方式就好，人与人看似是同个物种，差别之大和疯狂动物城里的动物其实也差不多了。
有这个时间，我会选择更关注自己的生活。

我个人一直觉得主观感受的时间流速和单位时间里接受信息的信息熵有很大关系。
年纪越大，工作、生活的很多事情对于自己来说就是重复的，并没有产生特别多新的信息量，所以感觉今年和往年也差不多，导致感觉时间流速很快。
如果每天有足够的变化，可能你觉得这一年的时间就不会这么快了

感觉我确实答非所问了（ x
不过要找一个**真正没有使用依赖注入模式**的 Go 复杂项目感觉还挺难的

就我所知绝大部分 Golang 开发的偏基础设施与中间件的大型项目（ Kubernetes 、VictoriaMetrics……），以及包括 Go 语言 Runtime/Compiler 本身都没有使用 DI 框架。

所有的依赖都是自己手动处理的，通过一系列的 NewXXX 函数以及工厂方法。很多 struct 可能就是全局的，在 go 启动时候就创建起来，然后在 package 范围内可见。在一些场景里可能会用一个比较大的叫做 "xxxCtx" 的上下文 struct （注意这个只是 struct 起了个名字，而与 context 标准库无关），用来维护传进来的 dependencies ，供这个上下文的方法使用，对于内部的 struct 有点像一个 DI 容器吧，但这个 "DI 容器"的依赖本质还是自己维护的。

个人觉得手动管理依赖并不是邪恶的，Go 的隐式接口实现可以做到不少代码较好的解耦（虽然隐式接口实现有单独的槽点），Go 项目里这些 struct 的设计也大部分实现了依赖注入模式（构造函数注入、方法注入），足以支撑复杂的项目。

然后 Go 项目很少使用 DI 框架，这样大型项目手动维护一个 "Unit" 几十上百个依赖是不是太麻烦了？事实在于，Golang 这些项目的开发者不少都认为一个"Unit" 不应该和所有依赖进行交互，而应该专注于具体的事情，去看这些项目的 struct ，他们的依赖基本上也是可控的，大部分都是最最多十几个这样了。如果一个组件依赖过多，可能需要思考是不是该重构了。

当然对于大规模多人的业务需求迭代频繁的大型 Web 应用项目，我觉得依赖注入 DI 框架还是有价值的，因为这种迭代变化频繁的项目可能会有很多业务驱动的 Service ，用 DI 框架能够提升开发效率，让搬砖的 IT 民工（比如我）不需要关注很多细节，但另一方面微服务模式一定程度上也降低了单体的复杂度，缓解了此类问题

@kneo 我觉得整体的交流讨论本身还是有益的，像我之前也一直把 goroutine 称呼为协程（ coroutine ），虽然我知道现在 goroutine 是抢占式的，但这么叫也说明我自己对于计算机系统的理解不够深刻。

就中文互联网而言，看到的诸多讨论、书籍，包括我之前面试字节的时候面试官都直接将 goroutine 称为“有栈协程”，这个偏差认知在国内应该是很普遍深入了，但反而是有引导到正确认知的价值，后续我应该也会尽自己所能去传播这类正确的知识。

@trzzzz 是指定时器的 duration 会加上 10% 抖动的做法吗？

在补 Better Call Saul 风骚律师，到第五季拉罗登场了
比 Breaking Bad 更让人沉迷

@Flourite 嗯嗯，我觉得其实不少点在后续诸位老板的讨论输出的知识内容里已经比较清晰了（虽然有不少价值判断与情绪输出 hhh ），这样读到的人在了解之后对于这些编程语言都会有自己恰当的判断。

此外这套方案是通过牺牲数据完整性来提高性能的，因为这里很明显会有一批热数据还在内存里没写到磁盘的，所以如果发生断电等事故（程序没有优雅关闭）势必会有一些数据丢失，如果要保证数据完整性就需要引入 WAL 日志机制以及频繁的 fsync 同步写入来保证数据落盘，这个会非常影响性能，所以看自己权衡了，但 IoT 场景应该还好要求不高？

这里说个不用轮子如果自己实现的思路，可以参考 vmagent 的设计：

https://jiekun.dev/posts/vmagent-data-structures/

程序内部自己维护一个内存的数据队列（在 Golang 就是 Channel ），一批接收请求塞到队列里的 handler （ cpu num 个 goroutine ），以及消费内存队列数据块的 consumer

请求会以 round-robin 的形式分到这些 handler 里，handler 需要把接收到的请求里的数据组装成合适大小的 block （可能是几十兆？这个是调优参数），然后当 block 足够大或者每隔一定时间后，handler 就把 block 刷到内存队列里

塞进队列之前，会有一批 worker （应该也是 cpu num 个）会序列化（ protobuf 或者自己定义的二进制协议）并基于 snappy 或者 zstd 算法压缩这批数据 block ，压缩的关键在于大大减小原始负载的数据大小，进一步增加后续磁盘写入 IO 的吞吐

consumer 会将内存队列里的 block 拿出来顺序写入到本地文件中，多个数据条目拼装的 block 且经过压缩，落盘的吞吐还是比较理想的。

你需求的数据量其实也就每秒 2M 左右，如果压缩一下甚至这个数据量会更小，所以理想情况下应该比较低配的机器就能够满足你的要求。

核心就是组装（其实就是 buffer 的思路）和压缩，来尽量提高顺序 IO 的写入吞吐，这是容易产生的瓶颈。

当然这套方案只考虑了写入，在查询上是没有什么优化的（没有索引），所以如果要实现比较好的查询的话可能还是要考虑开源的轮子，基于 MergeTree 的 Clickhouse 以及 VictoriaMetrics ，或者 InfluxDB 等时序数据库方案应该能很好满足这方面需求，但思路还是要注意写入数据库时数据的合并来实现对于 IO 吞吐的友好

@lesismal #11

> 通常的定时功能没必要加抖动, 这个库的具体内容我没看. 定时加抖动有可能是为了避免同时创建大量具有相同超时时间的内容, 后续同时到期去创建大量协程异步删除内容导致 goroutine 过多造成不稳定, 或者其他什么特殊的需要

应该是这样，像 Kubernetes 项目里也会用到很多 Jitter 去避免相同的超时时间（ https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apimachinery/pkg/util/wait/backoff.go#L203 ），像 kubelet ， 以及几个组件的 LeaderElection 都会用到，确实还蛮常见的。