@pod

这个没发 100%确定的。
我的方案是，假定碱性热水高压喷淋一段时间后，餐具一定会被洗净。
在这个前提下，如果餐具表面有油污，就会和水形成乳化溶液，浊度会有变化。
因此，我只需要比较当前洗碗机内液体浊度和清水的浊度，只要二者差值小于一个预设值，就认为餐具已经洗净（不然也没办法，不可能更干净了，可能得上钢丝球了）

用模版的 for index 是可行的。
我个人更倾向于使用 computed，给列表里面增加一个 seleced 的 key，值为 true/false。这样，无论后续是单选还是多选或者是 radio，都不用动逻辑了。
同时，这样做也符合 vue 逻辑和模版分离的原则。

你这里有个根本矛盾。我都合格投资者了，犯得着跟你一个不知道哪冒出来都平台玩股权众筹？
你说的这个模式本质上是低收益、高风险的。对于投资人，除了给个名字，给个 BP，连 BP 真实程度都没办法验证都情况下。你让投资人咋出钱？

认真的建议你穿西装，也就是 business suit 或者 business causal。
理由有三：
1. 着装正式体面，给自己以及交谈方尊重感。
2. 衬衫西裤，易于打理。每天蒸汽熨斗喷一下就好。
3. 搭配简单，出门不需要想怎么搭了，省时间。

@DOLLOR 你这个玩法我还是第一次见。挺有用的。

照着 redis 早期版本抄一遍。

@spadger 电烙铁哈哈哈哈，笑死我了。还一点毛病没有。

查找： ^((?!#))(.+?)((?<!\|))$
替换： $1$2$3\n

用了三个组：
第一个排除了开头是#（标题）
第二个排除了本身就是空行的情况
第三个排除结尾是|（表格的情况）

没必要因为用不用外键吵架。工程问题我们就应该从工程的视角去分析、判断。不要因为个人的喜好影响客观判断。

外键的作用就是在数据库层面描述表间关系。在这个基础上，提供了数据完整性校验的功能。

那么我们可以分析一下为什么互联网公司用外键的比较少了：

1. 业务没有定型，频繁修改数据库结构。有外键在修改数据结构时会比较复杂。
2. 数据结构简单，甚至退化成日志型。这里强调写入速度，外键提供的数据完整性检查会影响写入效率。
3. 有外键的情况分库分表会比较难处理。

那我们什么时候应该用外键呢？

1. 数据完整性要求严格。
2. 业务模型稳定的情况。
3. 软件开发的流程不完善的情况。从我的从业经验上看，文档能及时更新的团队真的不多。这种情况下，需要一个工具来快速理解业务结构。这时候，带有外键的数据库，我们有大量的工具来进行分析。

临时想到的就这么多，有补充的话请 @我。

我自己做的 Win7 带 NVME 驱动的镜像。下载这个就好了。

链接:https://pan.baidu.com/s/10FPPXj37cq2NN32e85VqAA 密码:hf14

你这样开发是没有问题。针对你的顾虑，你需要注意以下三点内容：

1. jQuery 和 Vue 仅在组件级混用，即所有 jQuery 被 Vue 封装。
2. 尽量减少直接 Dom 操作，使用状态来控制 Dom
3. 尽量使用 Vue 操作 Dom 而非直接使用 jQuery

cacti

这种需求在 OA 或者 ERP 系统里面很常见。做一个简化版的差不多一周工作量就可以了。
Vue 和 React 都有对应的动态表单组建。

如果想要在“简单”的基础上增加可配置性，事情就变得复杂起来了。举个例子，当一个表单里，需要通过一个 select 的选择，同时变化几个 Field 的值，这该怎么配置呢？

你怎么自定义的？

Voicemeeter
关键词：多路输出声卡

你提出的需求实际上包含两个问题。
1. 数据变更日志
2. 用户操作日志

问题 1 有框架级解决方案，一般叫做 ActiveLog。Django 有三个以上的库来解决这个问题。

问题 2 本质上是基于操作审计产生的需求，搜索关键词用 AuditLog 或者 OperationLog。但是因为这种日志往往与实际接口有关，所以还是需要逐个接口配置。尤其像你说的查询操作，这里查询往往会有多表连表的情况，直接记录表名不太合适。

综上所述，数据变更是对应数据库表的，一般框架都能处理。操作日志是对应接口的，因为框架很难确定你使用的接口规范，所以这里需要你单独处理。
操作日志的一个简易形式是字段形式式为 id operator api api_version request response。这个部分直接输出到日志文件里。而后配置日志文件的监听器，把需要展示给用户的部分再抓出来，这样就可以完整满足用户需求了。