工具是为需求服务的，不是用来制造麻烦的，如果你用工具感觉还不如不用，那就没必要硬上工具。

比如需求就是做一个表单页面，没有复杂的交互和数据流，这样完全没必要用任何框架和库，原生 JS 、CSS 、HTML 就够了。

技术选型不是选归宿，你在一个地方用 NPM 不爽，但在另一个地方可能不用 NPM 会不爽；所以用上 NPM 也不是说任何情况下都必须用 NPM，不用 NPM 也不是说任何情况下都必须不用 NPM，反正老板按照出的活给钱，不管三七二十一，能快速出活就香。

想证明自己居住满 6 个月，可以用租房合同来证明你在北京住了 6 个月以上就行，如果在亲戚朋友家借住，也可以让亲戚朋友写个证明。
这些都看你办证的派出所具体是怎么要求的，居住证办起来挺简单的，派出所的办事人员也会给你讲解明白需要什么材料。

居住证在办理个别业务的时候可能需要用，除此之外主要用途是作为积分落户的参考信息之一（居住情况）。

个人对 3B 的实践经验是，树莓派适合做 GPIO 的开发、老游戏机模拟器以及一些对可靠性没什么要求的辅助性设备，但其他用途都多多少少没那么合适。

首先，Node 的 REPL 环境和正常执行环境是不同的两个环境，而 this 是和环境相关的，在不同环境下调用 this 可能会导致返回不同的结果，这个建议看一下 Node 的文档比较一下。

然后就是分析两种环境下都应该输出什么值。

-----------
REPL 环境（直接启动 Node 进入交互界面输入指令）：
var x = 'x'; // REPL 环境下用 var 声明相当于在 global 上声明（你用 let 和 const 就不一样了），所以这句是在 global 下声明了 x，并赋值'x'。
console.log(this) // 输出的是 global 对象。

function foo() {
console.log(this.x);
}

// 和上面 x 的定义一样，这里在 global 上定义了一个属性 obj，obj 本身也是一个对象：
// 有一个属性 x，值为'asdf'；
// 有一个方法 f，引用的 foo 函数。
var obj = {
x: 'asdf',
f: foo
}

obj.f(); // 调用 obj 下的 f 方法，实际上是让 foo 函数在 obj 作为 this 的前提下运行，输出的 this.x 肯定就是 obj.x 。

var func = obj.f; // 这里是把 obj.f 的引用赋值给 func，而 obj.f 的引用值是 foo，相当于 `var func = foo;` 此时 func 与 obj 没有任何关系。

func(); // 因为 func 是直接引用 foo 的，相当于 foo 的别名，所以这一行代码完全等价于`foo();`；而 foo 是在 global 对象下执行的，this 也是指向的 global，所以 this.x 就是'x'。

-----------
正常执行环境（ node test.js ）：

// 正常执行环境下一切程序文件皆为 module，所以 test.js 文件里的所有代码也都是在一个 module 环境下的，而 module 初始情况下就是一个空对象。

var x = 'x'; // 只是在当前 module 作用域中声明了一个变量，但其并不是 module 的属性，所以这时候你用 this.x 是无法输出'x'的。
console.log(this); // module 直接作用域下的 this 就是 module 本身，这时候还没有为 module 声明任何属性和方法，所以就是个空对象。

function foo() {
console.log(this.x);
}

// 这里相当于是在 module 作用域中声明了一个变量 obj，同样，这个 obj 也不是这个 module 的属性和方法。
// obj 引用的是一个对象，这个对象有一个属性 x，值为'asdf'；有一个方法 f，引用的 foo 函数。这块和 REPL 中的一样。
var obj = {
x: 'asdf',
f: foo
}

obj.f(); // 和 REPL 中的一样，因为 f 是 obj 的方法，所以是以 obj 为 this 来执行的，输出 this.x 其实是 obj.x 。

var func = obj.f; // 和 REPL 中的一样，把 obj.f 的引用赋值给 func，而 obj.f 的引用值是 foo，相当于 `var func = foo;` 此时 func 与 obj 没有任何关系。
func(); // 和 REPL 中的一样，因为 func 是直接引用 foo 的，相当于 foo 的别名，所以这一行代码完全等价于`foo();`；而 foo 是在 module 对象下执行的，this 也是指向的 module，所以 this.x 实际上是读取 module 的 x 属性的值，然而 module.x 是 undefined （前面所有的声明的 x 都不是 module 的属性），所以就输出 undefined 。

有个问题，function anonymous( ) 是不是就不算匿名函数了。。。


> (function(){haha})()
Uncaught ReferenceError: haha is not defined
at repl:1:13
> (function a(){haha})()
Uncaught ReferenceError: haha is not defined
at a (repl:1:15)
> (a=function(){haha})()
Uncaught ReferenceError: haha is not defined
at a (repl:1:15)


注意看错误提示的内容是不一样的，后面两个会告诉你是“函数 a”出了错。

函数不直接发送数据，而是把数据存入本地的队列，另一个 setInterval 每隔一段时间把队列里的数据发到服务器，同时清空队列。

其实我觉得后端直接塞消息队列里是可靠性更好的方式。

https://developer.mozilla.org/zh-CN/docs/Web/API/Canvas_API/Tutorial/Optimizing_canvas
可能 Canvas 性能有问题，可以试着照这个优化一下看看。

另外考虑一下 WebGL ？

国内的 IP 跑这个服务会不会被请喝茶。

@ssqtctc 理论上来说病毒只要蛋白质和核酸没有被破坏，就肯定会保持活性的，病毒不需要新陈代谢，坏了就坏了，无法自行修复。个人猜测长时间暴漏在空气中的病毒如果逃过了氧化、阳光、高温等危险，也可能会被细菌等微生物作为蛋白质来源而分解。

不过电子设备，病原可以进去，那就肯定也可以出来，举个例子，电脑主机箱内部是有风道的，在风循环的时候就会带进去病原，那么如果拿到另外一个地方启动，机箱内的病原就会随着风道排出来，而污染这个新的环境。

找了一圈，可能无水酒精是个可以考虑的思路。

额，链接和后面的文字连一起了，你可以自己截一下。。。
MacOS 下应用程序除了一些使用高权限 API 的功能软件以外，基本上就是个.app 的文件夹，可以不安装直接双击运行，所谓“安装”也只是复制到你的应用程序目录下，方便下次找而已。

1. brew 不是苹果官方维护的，本身也重度依赖 GitHub，除此之外和其他包管理器没啥大区别。
2. 基本上都是下载 dmg 包，有的是压缩的 app 包，还有的是 pkg 安装程序，AppStore 很少用。
3. 很多指令虽然名称一样，但参数会有区别，比如 sed，因为 MacOS 上主要用的是苹果自己搞的指令，也有一些是来自于 Unix （非 Linux ）生态的，你可以用 brew 安装一个 coreutils，这个是包含了 GNU 的常用指令，和你在 Linux 上用的是一样的，安装的时候加上--with-default-names 参数可以“覆盖”掉系统的指令，这样在 MacOS 上跑一些 Linux 脚本就不会遇到兼容性问题。

另外安利一下我的工具箱 https://github.com/libook/IdleBox，基于 Zsh 和 Oh-my-Zsh，提供了一些配置文件和实用脚本。

个人经验来看，仅考虑写代码，如果不是有特殊需求的话，1080p 的 16:10 竖屏就非常好，符合一般的阅读协作习惯。分辨率再高的话可以亲眼试试对比一下 2K 和 4K，如果看不出来区别用 2K 就够了。

可以尝试容器技术，比如 Docker 或 Podman，可以在一台机器上同时运行多个隔离的环境，而且如果想重置一个实例到未使用状态也非常方便。

单机性能有限，而且随着微服务、各种中间件、Service Mesh 等技术的运用，多服务实例协同工作的场景会越来越多，分布式相关知识还是挺有用的。

底层可能都用了相同的供应商的机房，没啥区别，你只需要几家都谈谈价格，看哪个划算就行了。