React Native

不晚，只要 HTTP 协议不被淘汰，PHP 就不会消失。写 PHP 适合闷声发财的，至少可以把项目或公司做到千万营收，肯定没问题。把 PHP 主流技术搞熟练了，转 JAVA GO 什么的也不难。
另外：[W3Techs 在 2022 年发布了一份网站使用 PHP 的统计报告，结果显示：“在我们知道其服务器端编程语言的所有网站中，有 77.5% 的网站都在使用 PHP 。”]

"Edge 浏览器是为登陆状态"

时间过得真快都 12 了，我从 Debian Sarge 开始用的。

挺好，总结的不错。

这脑子好使，一看平时干过不少好事。

单独这个“复制”还是屏蔽，但用“剪切”就可以了。
另外再加一个 document.body.outerHTML=document.body.outerHTML;
去除所有元素所有事件，这样拦截也去了。但所有的点击事件也没了，不过这不影响不大，对于链接，还是可以通过右击打开。

完整代码
// ==UserScript==
// @name FUCK CSDN COPY
// @namespace http://tampermonkey.net/
// @version 0.1
// @description try to take over the world!
// @author You
// @match *://*.csdn.net/*
// @icon https://www.google.com/s2/favicons?sz=64&domain=csdn.net
// @grant none
// ==/UserScript==

(function() {
'use strict';
document.body.contentEditable=true;
document.body.outerHTML=document.body.outerHTML;
})();

程序员买什么车，我一年 1000 公里。开一年，机油都是金黄的，现在都改成两年一保养了。算下来，感觉不如租车。

还好没买电车，不然电池早就不行了。

一定要拔，我智齿拖了好几年，今年 3 月份拔了。我是水平高位阻生，拔的时间几分钟。没拔之前，这么多年，虽然没发过几次炎。但经常用牙线掏，牙线上会带血。拔牙后最大的改变是就，睡眠变好了。

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

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

就去搜猫眼摄像头（模拟），不要带“智能”关键字的。这种都是 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