今年硬盘太离谱了，买个网盘挺一阵儿吧。

可能表现过于强势了，和目标岗位不符合。

@selca 还真是，发现和 stackoverflow 是一家的，之前用 stackoverflow 多。这个网站倒是第一次检索到

同类竞品打差异化啊，譬如百度的服务是 online 的，有隐私问题吧。如果你支持接入本地模型。那就是类似云笔记有 notion 这种的，也有 obsidian 这种本地为先的，还有完全开源的其他自部署的笔记软件。

即使同一类产品，目标受众也会有不同，特性也会不同。

这个就如同完全让”智驾”在路上狂飙一样让人心惊胆战。

Maps are not safe for concurrent use: it’s not defined what happens when you read and write to them simultaneously. If you need to read from and write to a map from concurrently executing goroutines, the accesses must be mediated by some kind of synchronization mechanism. One common way to protect maps is with sync.RWMutex.
映射结构不适用于并发场景：当同时进行读写操作时，其行为是未定义的。若需要在并发执行的 goroutine 中对映射进行读写操作，必须通过某种同步机制来协调访问。保护映射的常用方式之一是使用 sync.RWMutex 。

This statement declares a counter variable that is an anonymous struct containing a map and an embedded sync.RWMutex.
该语句声明了一个 counter 变量，这是一个包含映射和嵌入式 sync.RWMutex 的匿名结构体。

var counter = struct{
sync.RWMutex
m map[string]int
}{m: make(map[string]int)}
To read from the counter, take the read lock:
读取计数器时需获取读锁：

counter.RLock()
n := counter.m["some_key"]
counter.RUnlock()
fmt.Println("some_key:", n)
To write to the counter, take the write lock:
写入计数器时需获取写锁：

counter.Lock()
counter.m["some_key"]++
counter.Unlock()

来源： https://go.dev/blog/maps?utm_source=chatgpt.com

@viking602 goland 有啥体验是 vscode 无法提供的吗，目前我 go 开发几乎都是 vscode 了，goland 尝试了几次，没用下去

@looplj WindSurf 的 Teams 里面最多能加几个人。

补上一个 Trae

claude code 用不到，疯狂封，只能 codex

GLM 肯定是比不上 Codex 。但是胜在省钱。

@juggtt213 没错，你说的这个场景正是我问问题时的场景。

MacOS+虚拟机，或许在续航上仍能一战。Mac 开发涉及到编译也很难和纯 Linux 一样，得操心一下一些底层的框架和库，毕竟和跑程序的主流的硬件架构以及 OS 都不一样。

@momocraft 感谢

所以说，所有的智能都得是辅助智能，全自动不存在的。让 AI 辅助的领域一定得是开发者能驾驭的领域。信马由缰大概率翻车摔沟里。出了 bug 用户不知道，开发者不会调，这个对软件来说是灾难。

如果另一个项目是你做的，那你这个不好说。如果是别人做的，你只是提了一嘴，那这个作者这个不好说

@isno 佬，我 23 年就看过你写的这个书，新版是不是相对于旧版删减了东西

朋友来了有酒肉，敌人来了有猎枪。