@zhouyin 这些真的是 mid 级在不包含系统设计的纯技术轮该问的问题，而且是 Python 后端应该会的部分…

而且其实这里面很多问题都真的一点也不过分，甚至你切换一下主力语言的话，这些问题大部分都可以平移过去的。

至于薪酬，国内的 mid 普遍给的都是 30-60 吧，但这不是我司的数据，因为我司并不在国内…

老实说全栈讲不出 immutable 实在是太水了，这真的不八股文了，而且问的也不难…

要我的话，如果你 py 是主语言，我大概会问这些难度的东西：
threadlocal 实现
asyncio 的 task 的线程安全
timezone native 和 pytz 的坑
pydantic 和 dataclass 的行为区别
Annotated 和 annotation
contextvar 为什么是 asyncio 安全的
给一个用 LOAD_FAST 优化的用例
cffi 和 raii
poetry 、pdm 和 uv 的行为区别
WSGI 和 ASGI 的中间件

这才只是面 3-5 年会问到的难度，8 年的 py 技术岗的技术面怕是要连 six 、future 和 past 甚至是 asyncio 发展史和 gevent 都问了

而且上面的全都不八股文，全是我实际用到过的东西

pg ，说实话 my 会死锁这个设计始终非常弱智，但是 pg 的 vacuum 有时候有写入性能和占用空间的坑，上个透明压缩会好很多。

系统目前是 15.1 ，这毛病看来 15.2 也没修。

看了一眼，uptime 71 天，这玩意现在吃 18.8G……

讲道理 snipaste 缺功能确实很头疼…

基本上 amd64 的性能只能达到原生的三分之一到一半，够用是够用的。

另外需要更新到新系统，至少 sonoma 吧，旧版本有一些奇怪的 rosetta bug 。

另外 docker desktop 还是推荐用，比 orbstack/colima/rancher 要好，一个比较突出的点是它设置 swap 很方便，而 rancher 需要在 docker host 上跑命令才行，colima 更麻烦。

还有 docker desktop 是可以在 vm 外修改文件之后触发 vm 内的重打包的，而替代品们都很难实现这一点，这个对于 jetbrains 系这种不完整支持 remote 的 ide 来说很头疼。

其实会更希望这样的 app 可以做到导出和导入 keychain 追踪信息，这对于切换一些依赖它实现的账号绑定来说还蛮有用的

@lizhisty 试了一下，体验上还是不如原生 swiftui ，但是差别已经比较细微了，主要还是无限列表滑动的手感有区别，比如滑动到底部需要加载的时候会骤停，view 导航右划返回的时候动画速度没有动量。

补充一条，合理的缓存策略也很重要，很多请求是不需要疯狂刷查询的，oauth 之后给每个 token 做一下 rate limit 很重要。

不要用 protobuf ，用无需自解释的协议，比如 flatbuffer 或者 capnproto ，可以省去一大波结构描述类的开销。

另外 graphql 真的省带宽，按需给字段很重要的。

还有你需要 zstd 。

优泽 Xyzal 是左西替利嗪的原始研发厂商推出的商品名，其他都是仿制药。

api 少推荐 axum ，多推荐用 poem ，后者的自动文档生成很好用，两者其他方面体验相似

@Andim 非常不推荐使用这个备份功能，因为它在跨系统版本的时候备份是不能还原的，即使是跨小版本也不可以。如果你有无法降级并且新固件不支持旧系统的固件升级，那么这个备份也会失效。

@AthensBird 现代液晶黑体都是适用于小字号正文排版的黑体，字形上大多为了正文排版的辨识度做了妥协，就算雅黑以外的中宫没有那么大了，但笔画结构的妥协还是很多，这和喇叭口黑体一样。

另外，字幕是 Subtitle 啊，title 系是不用抠死去推荐使用正文字体增加可读性的，何况也不增加。

> 它似乎更应当搭配一种更具现代感的黑体字，以更好地符合其科幻的内在氛围。

---

不是。网飞三体使用的镜头质感甚至比腾讯三体复古的多，很多镜头有胶片感。

而且偌大的屏幕每次就一行字，这完全就不是现代液晶黑体的应用场景。

首先就像喇叭口一样，适用于液晶显示的黑体也有大中宫的毛病，同样也不好看，甚至还更不好看一些，因为中宫大小扭曲的是字形。

其次，你忘了胶片也是模拟信号，也是“印刷”的，喇叭口无可厚非，并且喇叭口是有种美感的，就像你不能一味否定 grotesk 一样，古早的味道是影片制造里很重要的一部分。

snowflake 存成 char(19)…是 bigint 有什么短板吗