@wpzz #10 说反了吧，越来越多的年轻人进入工作，越来越多的 35 一刀切，切完就没什么养老压力了

我还以为是原创呢，原来都有

找工作，还欠资本一屁股

写脚本分别部署吧，拼在一起，在一台机器上也是一键部署

刚好最近看过，postgres 有 row level security ，数据库层级对访问/操作进行控制，就是对应这种需求的，不知道你们用的数据库有没有类似实现

现在剪发价格是多少？几年前有次回家（不是过年）在镇上路边店剪被收了几十（不超过五十，但也不少太多，具体记不清），是不是被黑了，还以为物价飘了。这两年都是老婆给剪的了

@sun1991 看描述，合理的理解可能是，源不是 oracle 兼容，或者自定义规则空字符串有效，信创库是 oracle 兼容，导入后空字符串因为某种机制转换为无效值

受影响的人管不了，能管的人不受影响，甚至。。。

看起来意思是同时只要一个 delay 长链接，建议自己 promise 队列

同一个 get 请求的并发数是 1 这个有出处吗？

看起来没人理过这条，个性化推荐，第三方共享数据的处理也流于形式，个人选择权几近于无

https://nmca.miit.gov.cn/zwgk/zcwj/flfg/art/2021/art_0bb3c8d9e620423fb4deeb85e1b751c5.html

> 第四十五条　个人有权向个人信息处理者查阅、复制其个人信息；有本法第十八条第一款、第三十五条规定情形的除外。
> 个人请求查阅、复制其个人信息的，个人信息处理者应当及时提供。
> 个人请求将个人信息转移至其指定的个人信息处理者，符合国家网信部门规定条件的，个人信息处理者应当提供转移的途径。

看 op 描述，是超出风险承受能力（心理上），其它内容在论证这个结果

@Chuckle 不定高的问题是滚动条，普通元素的滚动条是和内容线性对应的，虚拟列表要手动对齐这部分交互体验。

以你的 demo 为例子，不定高度一页是 2000 条数据，ctrl+end 定位的话尾部应该是第 2000 条，我这里操作结果是 1946 。再一个是拖动滚动条，能明显看到鼠标指针和滚动条慢慢错位。

滚动条拉到一半位置，定高只要按索引折半，再细点就算上容器高度，简单的计算。不定高就不一样了。

碰到不定高度的直接想法就是算出来缓存，后台绘制，缓存。问题是虚拟列表数量往往不会少，就算只绘制一遍也是不小的开销，要是再加上加载图片的场景，时间和精确至少少一个。

后端给出高度也是一个方案，不考虑后端如何得到数据的问题，前端的一个问题场景是不定宽度的容器，数据高度受宽度影响也会变化。

不考虑滚动条的事行不行？也可以，虽然体验有区别，细节处大部分人没碰到也不会在意，也许以后大家都默认虚拟列表的交互就是这样的