我买的 mbp 附带的 magsafe 线充不上电，一直是橙色，只能用 typec 充。去苹果店换了一根。偶尔有问题无法避免吧。

我敲每个键都是闷闷的声音呀，空格键因为长，手感稍有不同，但没有特别的声音。感觉你可以去店里试试。

```sh
git mv foo foo2
git mv foo2 FOO
git commit -m "changed case of dir"
```
摘自 https://stackoverflow.com/a/3011723/502851

@lddsb 哦，那可能是我记错了。或许是当时 iOS 没有双拼，所以用 gboard ，但 gboard 在 android 没分号，然后就选小鹤了？上年纪回忆都模糊了～

为了用原生，把常用双拼输入方案从微软改成小鹤了。除了偶尔会搞混，也没遇到过什么问题。

@IGJacklove 同感。写业务逻辑最多就是写精巧一些、健壮一些，体现不了特别多技术。感觉靠我自己赚不来工资。

我买的 innocn 外接屏幕，用 typec 也是唤醒失败。看设置里显示器在，但就是不亮。得拔下再插。换用 hdmi 没问题。

@lamls 正常频率说是一万赫兹，应该不低，比手机上几百要好很多。但我怀疑在纯黑背景的时候频率不正常。不过知乎回答里说普通 LCD 频率都是十万赫兹，所以对比下来就差一点。

依我看，这不是 VSC 的问题，是代码文件的问题。这点 go 语言做得不错，同一 module 下随便分多少个文件都可以。

单身生活多爽呀，拖家带口烦死人。

同意楼上，一个本地 git 文件夹可以与多个 remote （远程仓库）同步的，自己可以找个安全的远程仓库用。不过公司代码比较敏感，要注意。我个人有用 keybase 自带的号称加密过的 git 。当然其他人说的用开发分支也是常规手段，一般都可以开新的开发分支。git 的用法就是每个小修改都提交，然后最终往 master 合并的时候再合成个完整的。

厉害，很有领导者的气场。OP 从小就有这种组织能力吗？是父母培养还是性格就这样子呢？有没有总结回顾呢？

@IslandOwnerHuang 微软为了兼容什么都可以干出来。苹果完全不考虑兼容，历史包袱轻，迭代速度快。

@iosyyy 哦，你是说 copy on write 是另一种思路，我之前没理解你的回复。copy on write 明显更难实现一些，成本更高一些。go 的设计理论是用 CSP ，就是把对同一变量的同一时间的操作限制在同一协程里，用 chan 在协程间传递命令或结果，这样对所有变量（不仅仅是 slice ，最普通的变量都不应该同时被多处读写）操作前都不用考虑锁的问题。如果是初学 go ，建议尽量往这个思路上靠拢，因为理论上是完备的，所有问题肯定是可以通过这种思路解决的。但是 go 不像一些更前卫的语言直接封掉了协程间共享变量，还是保留了锁，就是在一些特定情景下，直接用锁更直观。这就跟 go 保留了 goto 语句一样，你总是可以用别的方法避免 goto 的，但有时就是直接 goto 更清晰明了。像 sync.Map 这种封装是直到 1.9 才放出，就是因为官方认为这并不是必要的。现实总是充满各种妥协，官方为了避免一些用户自己实现出问题，还是集成了 sync.Map ，在 https://pkg.go.dev/sync#Map 文档里说了，只在特定场景中使用。

你后面说的线程我不太理解，协程已经把线程池这个概念封装掉了，不用让每个程序员都直接处理一些底层优化。不清楚你说的无脑是什么意思。

@iosyyy 我说的 chan 或者锁，两者都跟 copy on write 没有关系。之所以 go 官方没有楼主说的功能，是因为不需要，用别的思路不需要 slice 本身线程安全。天下没有免费的午餐，保证线程安全是要有代价的，go 希望开发者自己选择承担多少锁的时间，而不是直接无脑使用一个库。

用 chan 的意思是，把对同一 slice 的操作控制在一个 goroutine 里，这样就不用考虑锁的问题。
没有现成的是因为锁的需求场景都不一样。比如有两个 slice ，你可以用同一个锁限制他们的访问。拿到锁了，就可以对 slice 做很多放多操作。但是如果是别人包装好的，为了保证不出错，可能每次查询都要锁一次，效率太低。

有可能公司不知道是谁的 id ，所以也没联系你。你不退 id 别人不知道密码也没法退呀，手机一更新系统就锁了。