褪黑素我也用过，都不能维持太久。时间长了还有副作用，睡醒后头疼。

先治疗牙周病（什么智齿蛀牙什么的）和消化系统疾病。达到用牙线牙龈不出血，每天大便成型。这时候睡眠自然就好了。

就去搜猫眼摄像头（模拟），不要带“智能”关键字的。这种都是 12V 供电的，再去买硬盘录像机，挑那种最便宜的买就行。

> "反过来，有另外一个问题。
别人让你报价，比如你成本 5k ，你报价 1w ，中间人给客户报价 2.2w ，会有什么问题。"

前提是，中间人直接和客户对接。中间人全款我，我按实际 5K 的需求完成。中间人报 10W 也不关我的事。

如果 2.2W 是我跟客户谈下来的，那最多给中间人 3K 。

> "举个例子，界面上一个** [树形选择器] ** 里的数据，需要一个状态判断是否展示，但是这个状态在另一个微服务里。后端表示让我调两个接口，然后根据数据再过滤一下，可特么这是一个树形数据啊，不是说做不了，但这让数据库 sql 过滤不是更简单，据理力争之下后端才妥协。 "

树形数据的接口，是不是只有这一个界面调用？如果是，那按前端的显示状态返回就是合理。如果不是，那就会有多种状态的可能。下次有其它状态，就得重新出一个接口，这样接口就冗余了。当然也可以整合在在之前那个接口里，这样就耦合了。

spring boot 里 RPC 调用很简单，也就几句话。但并不会出现“这让数据库 sql 过滤不是更简单”。微服务下，这其中的工作量并不会因为转移到哪个端实现，工作量就会变少。


> "意思是前端能调就前端调，在业务不得已的情况下是不会写 rpc 接口的"

微服务不但要避免 RPC 调用，还要避免 join 。

正确的做法是，树形数据的接口不变，只负责完整数据输出。其它服务根据自身的需求出状态接口，如包含所有要显示的 id 数组。前端只是在遍历树形数据时，顺便判断一下 id 是否在显示状态接口的 id 数组中，这能有多大的工作量。这样出现其它不同的状态需求，只要换一个状态接口就可以了。目前，无非是后端妥协了，在后面用 RPC 调同样的接口，把数据处理好返回。下次呢？再妥协，一个接口里加一堆 RPC 调用。最后，这个接口的并发肯定上不去，变成系统的一个短板。

同时，有（输出）状态接口，必然有设置状态的接口，这个也和状态接口在同一个微服务里吧。既然和“树形数据”分开了，说明树形数据只是其它业务的子项，是一个公共服务。在公共服务里强行耦合其它业务，也非常不合理。

举个实际的例子，如地区数据服务，需要在很多业务里调用。有些要省市的，有些要到地区街道的，有的要在一个范围里的。如果在接口里做显示状态的判断，那么每次调用都得做一遍无意义的计算，还要传一坨数据。如果显示状态独立出来一个接口，用白名单或黑名单，在前端判断。地区数据只要获取一次，缓存好。这样不管是前端还是后端，性能会更好，还会节省服务器 CPU 和带宽资源。

> "后端甚至一些业务逻辑都不写了，举个例子，一个审批流程，按业务流程来说，应该是轮到自己审批了才展示。目前是只要和自己关联统统展示，并且要前端来通过代码判断是否轮到了自己处理了，才展示对应表单，这合理？"

都“按业务流程来说”了，就变成流转中的业务要不要展示？审批过后要不要展示？工作流不会一直向前流，还有回流，如驳回后要不要展示？驳回后，按业务流程来说，就是还没轮到自己审批，是不是不应该展示？什么叫合理？我早上上班，看一下最近和我有关的审批事项，提前熟悉一下相关事项，准备好相关资料。等到我审批时，就直接提交，这样做合不合理？比如，在电子税务局里，常会出现一些项目没到申报期，点进去也不能申报。但会提示，还有-xx 天，这样合不合理？


最后，10 几年前，是没有前端这个职业，基本只有美工和程序员这两种。还有很多美工都是由程序员兼职的，比如 V2 就是那个时代的典型。当然了，现在后端兼职前端的也不少，像 V2 这样就不需要独立前端。前端的出现，就是因为可以把原本在服务端的计算放到客户端，节省资源提高可用性。做为一个合格的前端，应该是去压榨客户端资源，而不是服务端资源。不然前端就失去存在的意义。

群晖之类的 NAS 系统，本来就是缝合怪。缝合了一堆开源工具，就拿出来卖了。

把地址准备好，自己去跑，不用钱。这里面最麻烦的就是银行开户要现场拍照，所以要借个地方。做帐很简单，到 acc5 上学一下。去下一个做账的 excel 文件，或 X 宝上淘一个。那些 800 的会计，其实基本不做账。就是到电子税务局里给你零申报，就点几次鼠标而已，键盘都用不上。要是开发票了，要做账了就得加钱。

Mojave 10.14.6

不错，不过我平时主要用 emacs ，vim 的主要作用就是改 emacs 的配置和查看文件。

"有网络请求的情况下切换页面时观感上会没那么快，一般会用哪些手段提升体验。" 快不快不能用感觉，要用 waterfall 的数据来对比。对于后台管理这种没有什么并发量的系统来说，同样的业务，用 react 等现代框架实现一般都慢于用 jQuery 经典技术实现。数据渲染，中间计算的代码越多就会越慢。所以现代框架通常都会有转场动画，让人产生一个流畅的错觉。比如用 jQuery + PHP 实现的管理后台 dcatadmin ，目前还没发现用 React/Vue + PHP/Java 的管理后台能比 dcatadmin 快的。

而且直接开通支付，默认费率最低也只有 0.6%了。

换四大行。我 20 年换成工行，上来就问你 1 天 50 万，够不够。

用 vultr 的有很多，这还是第一次听说。

同 15 款，不过是 16+512 版本，mojave 系统。现在 chrome 50+ tab ，emacs + lsp java 开发，内存用掉不到 8G ，还是比较流畅。内存升级也是很成熟的技术了，只要颗粒没问题，基本都是很稳的。

一键给所有的 VPS 装 httpd ，想想就刺激。

@lovestudykid 如果真这样的话，那就得要求 GTP4 对日常生活中正常的图片文字（各种字体，包括二次拍摄的图片）的 OCR 准确率能达到 100%，才能谈不需要训练也能秒杀大部分验证码。 不过，GPT4 已经发布一个月了，还没人发现它有这种能力。

图片验证码其实早就没作用了，10 年前的打码平台就已经在用卷积神经网络训练识别验证码了。对于图片验证码，只会有人能识别，AI 识别不了的。人只要认识常规的字母和数字就行，而 AI 识别的前提是对各种样式的验证码进行学习，没学过的就不太灵了。不过，AI 现在可以生成图片，那么也可以生成不同样式的验证码，反而能提高验证码的破解难度。

就拿《我再也不敢装逼了》这个帖来说。一个新用户进去，啥也没干就能消耗掉接近 7M 的流量，json 换 MessagePack 就没什么必要了。

大行 D6