我认为分 IO 和 CPU 密集型

如果是 IO：
1.上多线程
2.上异步

如果是 CPU：
1. 不要管
2. 用其他语言如 C 重写关键逻辑，或者整个逻辑
3. 换解释器，如带 JIT 的 pypy

https://v2ex.com/t/797765
https://v2ex.com/t/844528

可能是中国团队之间的合作

微软电脑管家只提供了中文版，换成非中文可能就不推送了？

物理定律还有适用条件呢，更何况数据库的访问模式不同，硬件、软件也会不断地迭代和优化

#1 @Livid 说的并不正确，时间戳会出现负数，并且负数表示 1970 年 1 月 1 日之前的时间，所以不适合用无符号，应该用有符号。

就我所看过数据库的文档，就算有了索引，数据库还会采集数据的元数据做辅助判断是否使用索引。用 explain 查看数据库实际的执行计划才是正解

个人觉得应该调整写代码时心态：不要小瞧任何一项小功能，一个小功能背后，其实有很多的看不见的大功能支撑

在时间允许的情况下，设计好代码结构，尽量考虑各种边界情况，给未来的代码预留扩展空间，做好代码模块的封装，了解背后接口 /功能的大概实现，每一行代码都做到心中有数

比如在兼容代码这块，其实背后有很多的设计思路可以挖掘：代码层面，程序之间 api 层面，数据结构，业务上，项目上。然后扩展到设计模式，api 的设计，数据结构上的设计，用什么方式，既能不破坏现有的功能，又能增加新的功能，尽量避免引入新的 bug

当然，这些都是软技能，不是什么我学会了 xxx 框架，xxx 语言，挖掘支撑小功能背后的知识，找到自己感兴趣并有学习动力的知识点最重要

我自己经验也不足，希望这点经验可以帮助到你

我 8 月 30 号也刚离职，仗着年轻，除了生活费和房租，没有其他大开销，还在潇洒当中

软删除有一堆需要考虑的细节问题，关联表同步，唯一性破坏，查询条件带软删除标记，统记时数据清洗，空间占用。

性能最佳的不一定就更好，我一直不太喜欢 chrome 开发者工具的主题配色，反而觉得 firefox 的更好看。chrome 强制推进 manifest v3 ，导致广告拦截扩展基本不可用，也导致许多人不满。

看了文档，当你监听了 SIGINT 信号,就相当于覆盖了 go 对 SIGINT 的默认行为（退出程序）

简单方法：让 main 函数也监听 SIGINT 信号。

搜索了一下，rfc 2047 规定了邮件里面如何表达非 ascii 编码的文本，你发的文字就是经过 rfc 2047 规则编码的文本。我不懂 php ，但是 https://www.php.net/manual/en/function.imap-mime-header-decode.php 好像可以用

不知道有没有纯 js 实现 和 wasm 实现在处理速度上的对比？特别是不同数据大小对处理速度的影响。 还可以对比不同浏览器的 js 引擎的影响。

这样是不是搞插件化会是更好的选择。每个插件独立维护，允许内置，允许覆盖更新。当然要怎么设计插件系统是个大问题。

恰好我比较常用 createObjectURL, 有一些优化点：
- 可以用 fetch 直接下载 DataURL, 比如 fetch("data:text/plain;base64,aGVsbG8K")，省下中间转换的过程。
- 使用 createObjectURL 后，对应数据会一直存在内存中，调用 revokeObjectURL 才会释放

没有人规定容器里面不能使用 supervisor 。

但是容器只能监控第一个启动进程，如果使用了 supervisor ，那么容器监控到的是 supervisor 状态，而不是具体服务的状态。
在容器内使用 supervisor 带来比较明显的缺点：
- 进程监控（ docker 只能看到 supervisor 的存在，无法感知 supervisor 背后启动的服务, 比如 docker ps ）
- 日志管理（如果服务直接往 stdout 输出日志，日期可以被 docker 收集，如果加了 supervisor 显然不能直接收集）
- 信号处理+服务重启 (docker 重启服务时，会先向进程发送信号 SIGTERM ，此时服务可进行后续处理，超时才发送 SIGKILL. 使用 supervisor 可能需要进行额外配置，同时重启 supervisor 会将后面所有的服务都重启)

同时一个服务一个容器，可以很好的利用现有的容器监控方案，然而使用 supervisor 就失去了这些优势。

没有人规定容器里面不能使用 supervisor 。

开启 clickhouse 的 query_log, 里面有客户端，IP 地址，执行了什么语句，基本能确定谁写入 /谁查询。


https://clickhouse.com/docs/zh/operations/system-tables/query_log/

我建议参考 http 协议自带的缓存机制，etag, if-modified-since 等。每次请求必须都向 A 发送请求，有更改重新获取更改后的内容，没有更改继续使用缓存的内容。

#2 的做法不可取

OP 的需求是获取渲染文字时所占用的宽度，不是简单用 "字符串的长度 * 字体大小" 就可以解决的。

比较显著的因素有：字体的选择，字体大小，字符的间距，行高，字体是等宽还是非等宽，渲染效果，实际的渲染环境等。这些都会影响渲染后字体的宽度和高度。

建议查阅所使用绘图的 API 文档，一般都会提供 API 用于测量字体的渲染信息。比如

https://docs.oracle.com/javase/7/docs/api/java/awt/FontMetrics.html

https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/measureText


关键词 FontMetrics, measureText