可能是本地安装依赖的时候更新了依赖版本，跟上次构建时依赖不同导致的

如果可以找到线上版本构建的依赖版本，本地固定 version 测一下应该就能复现

早上脑子有点混乱，要不要用静态看的是数据结构，如果这条数据跟某个实体有关，那就是实体的一部分，反之如果所有实体共享某个数据，就用静态；至于缓存、实时这些概念就按生命周期这个思路去思考一下吧，感觉很主观，说多了也没啥意义

缓存这块我描述的有问题，场景有很多

用存储过程最常见的场景就是你需要用到大量的基础数据做计算，拉到内存里又明显的耗时又浪费资源，这时候就要用存储过程

静态、非静态本质上要看数据的生命周期，例如伴随整个程序生命周期不怎么需要改动的就用静态，如果要实时更新的数据就去库里面取，如果要更新但又不是很频繁的，就用缓存，管理好同步问题就行

与其说是安全隐患，倒不如说是隐私隐患，比如你的家具使用信息被人窃取，小偷、推销、诈骗就能按照你的生活方式、个人喜好制定有针对性的方案，就看你身上有没有值得被针对的目标了

村通网

A：阈值
B：啥？
A：阀值
B：哦

这种时候你要用哪个？

有枪可以为所欲为

终于看到踩坑 vue3 的了

英语好的话，可以试试墙外的辩论节目

我觉得你应该从记者或媒体方向来找答案，医患事件为什么会发生，患者经历了什么？只有基于事实的探索才能真正的引导医疗行业的健康发展

你需要的不是更清量的脚手架，而是一个项目模版，引入了 element-ui 并且开箱即用的那种

从 micro task 的角度看，promise 本体在 current task 中执行，then 里面的回调被添加到 micro task 队列中，而第二种写法里面的 catch 是在 then 所属的 micro task 被执行时才被添加到 micro task 队列的，所以：
第一种写法：三个 promise 依次被添加 then 里面定义的 micro task，得到队列 p1-then 、p2-then 、p3-then，p1-then 的 reject 回调会赢得 race ；
第二种写法：三个 promise 依次被添加 then 里面定义的 micro task，micro task 的执行结果会得到新的 promise，继而依次添加 catch 里面的 micro task，完全执行下去会有 6 个 micro task，依次是 p1-then 、p2-then 、p3-then 、p1-catch 、p2-catch 、p3-catch，p1 的 then 虽然排在第 1 位，但只是返回了一个新的 promise 并将 p1-catch 添加到 micro task 队列，并没有回调 then 的第一个参数，所以 p2-then 赢得 race 。

分两种：
1 、现有数据结构跟原型差别很大，原型里面的某些东西做不出来
2 、能做出来，但是前端工作量很大
解决方案：
1 、项目初期尽快找出这类问题修改原型或接口
2 、与产品、后端沟通协商，尽可能解决原型与数据结构不协调的问题

@boris93 楼上有人提到的一部分已知一部分未知的验证码，利用已知部分进行验证、未知部分用于训练的说法还说得过去，不过你说的这种我觉得就很难实践了

这就有个问题了，验证码肯定是有标准答案的，用户点击提交的答案用来做什么呢？对比 ai 跟人哪个正确率更高么？

二维码的作用是可以让 app 从一张图片里面读取出一串字符串，通常是一个 url 加一堆参数；
目前的图片识别技术理论上可以做到同样的事情，例如手机拍照读取墙上张贴的一个转账信息：{app:"支付宝",target:"老板",method:"转账"}，但你还是需要使用一种特殊的方式去写这段文字防止太长，用特殊的字体防止摄像头识别不了，条条框框定义下来还不是跟二维码差不多

lambda 不就是一种定义匿名方法的语法么，怎么就跟线程扯上关系了？