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

恰好我比较常用 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

感觉是 X-Y 问题，同时没有完整的代码上下文。

我推测你遇到的问题是：在 preview 的回调函数无法指向你期待的 this 对象。
原因：function 内的 this 会根据执行的上下文发生变化
解决方法：
1. 用箭头函数，让 this 指向声明时的 this
2. 用 bind() 显式绑定 this

返回 func 可以链式调用？ func(list)(list1)(list2)

SQL 适合数据处理，清晰的业务处理，但不适合嵌入复杂的业务逻辑。比如考虑节假日，这明显就不适合纯 SQL 做。

我目前就在用 go 写业务，说实话，不合适。虽然是强类型，但是类型系统弱，需要写大量的代码去处理类型 /数据结构上的转换和封装，判断 err ，判断 nil ，语法糖基本没有。

select
class_id,
course_id
from (
-- 根据每个班级下的选课人数, 给课程确定顺序
select
class_id,
course_id,
stu_cnt,
-- 根据选课人数降序
row_number() over (partition by class_id order by stu_cnt desc) as r
from
(
-- 先统计每个班级, 每个课程的选课数量
select
class_id,
course_id,
count(1) as stu_cnt
from
t
group by
class_id,
course_id
) as t1
) as t2
-- 课程排第一的数据
where r = 1;

这种如何：

先拿到用户已使用的产品列表（数据规模较小 ）：

select * from 产品 as a
where exist (select 1 from 产品使用情况 as b where b.用户 ID = 目标用户 ID and a.产品 id = b.产品 id and status=已使用)

其中，产品使用情况表只存储用户有使用过的产品，没有使用过的不要存储。如果用户曾经使用过某个产品，但后来又不使用了，可以更新状态，或者删除记录。

然后在查询的时候排除掉已使用的产品：

select * from 产品
where 产品 NOT IN (用户已使用的产品列表)

我认为是对的。但是 python 是解释型语言，应该先从解释器角度去理解。

比如 https://docs.python.org/3/faq/library.html#what-kinds-of-global-value-mutation-are-thread-safe

描述到，python 解释器的执行单元是字节码指令。字节码指令背后的所有 C 语言代码执行也是“原子操作”。当一个字节码成功执行后，其他线程才有机会拿到 GIL 。

CPU 还有各种缓存和指令执行顺序问题，那就更加复杂了。

@jmqrock2020

总之，有多线程就要考虑并发读写变量的情况

python 不是有一个 GIL 锁吗，理论上是可以多线程同时操作同一个列表对象的。当然最好的方法还是用自带的 Queue (有多线程和多进程的版本).

为什么都搞小程序呢？写成博客或者 CMS 不是更好吗，并且也可以被搜索引擎收录，给中文互联网增加新内容

我的方法：将字符串解析成可处理的 HTML 对象, 找到标签 span, 检查内容是否符合条件，然后替换标签。替换结束，再序列化成字符串。

比如用 DOMParser 解析： https://developer.mozilla.org/en-US/docs/Web/API/DOMParser

同建议定时任务，每次扫数据库就可以了。
等到数据量大，延时不能忍受的时候，再考虑其他优化方案。

docker-compose 输出带转义序列的编码(ANSI 颜色代码, ANSI escape sequences, ANSI color codes)的日志，最好的做法是除掉转义。

0. 关闭 compose 的 ansi 输出. 看文档似乎 --no-ansi 可以关闭
1. 输出管道中间加个可以去除转义的程序, ansi2txt 或者 sed 替换
2. 切换到 非 tty 模式(一般程序检测到 tty 才会输出颜色编码), 比如 ls -cl < /dev/null |& cat

搜索关键词：drop ANSI color codes,

search after 也可以啊.
确定一条消息的唯一性可用的属性有：发送时间，消息 ID ，消息来源。只要 "消息 ID"+"消息来源" 的组合你如果能保证唯一性就可以。

然后用 search after 搜索，排序用这三个字段，就能保证不重复获取