理论上是这样，但是实际上估计并不可行，主要是系统中有很多任务是需要在固定的时间内响应的，比如有些中断，你无限分配 cpu 那每个虚拟机被调度的时间会大幅不确定，部分依赖确定时序的任务十之八九肯定会出错，这样肯定不行，应用层大多不怎么依赖确定时间或确定时序，但是底层硬件相关的可就不一样了，否则 cpu 为啥都有依赖高精度晶振

@des #5 不需要全网段扫描吧，各大 IDC 和运营伤分配规则都是公开的，其实也只需要扫可能被分配的网段或地址就好了

@phpfpm #14 操作系统也可以限制某个进程的 cpu 使用率的，本质上两者没啥区别

@phpfpm #10 两者都要做吧，否则万一你操作系统有 bug 或者本身就是恶意操作系统那岂不是提供虚拟化的宿主机都要挂了，比如阿里云这种一台物理机虚拟好几百台万一你买的那台其他虚拟机有人干坏事你担心？程序对操作系统也是一样的，操作系统和虚拟化一般不会均匀调度，只要有可能还是优先放在相同 cpu 的，毕竟可以提高状态、缓存、中断相关效率

@phpfpm #7 最大问题，“会被调度到多个核心”和“会被调度到多个核心上并行执行”是两回事，前者并不能提高性能，对于后者来说，既然你程序已经多核不支持并行那么后者并不能超过你程序实现来通过调度实现，有没有虚拟化都不能

虽然屏幕不发光了，但是估计 CPU 和 GPU 不能进入低功耗休眠状态，屏幕刷新率也还要维持，估计省电效果要差很多

@Felldeadbird #4 云网关，无法离线使用的都是需要接入远程服务器的，比如米家都是从米家服务器中转命令。设备长连接接入米家服务器就可以实时响应你的操作了，那些纯局域网的就更简单了，设备发现时已经记下了 ip 和 mac 地址，直接给对应地址发送命令就是了啊，前者问题自然是远程服务器崩了你就操作不了设备了，比如前两天米家还崩了多有米家设备都没法用还冲上微博热搜了，后者如果你设备从路由获取的 ip 变来变去大概率是用不了的，而且出门后手机不连接相同 wifi 也用不了，当然本地控制也有其他方案，比如广播消息或者 mdns 啥的

你一个程序不止载入一个库吧，每个库都是单独编译的，那么也就是程序编译的时候其实无法确定实际地址，需要在程序载入的时候完成地址重重定向，只有绝对地址的话也就意味着你要把所有指令重写一遍，而且不同程序载入的相同库不能共享，有相对地址就简单多了，不同代码和库编译成不同段，地址编译成段内相对地址，载入只需重定向段基址即可，而且更厉害的是这个相对地址加段基址的选址过程完全由 CPU 的内存管理器自动完成，不会造成运行时性能损失，此外不同程序载入库的问题也可以放到统一的物理内存之中之后再通过段基址映射重定向到每个程序需要的地址去，大幅节省内存，我记得应该是这样的

@12101111 #17 原子引用计数单个确实不高，但是明显你忽略了引用计数需要的操作数可是远远超过了 GC 的，引用计数只是不会导致全局暂停延时而已，并不能降低整体延时，甚至是增加延时的

MQ 加工作机 1 工作机 2 两个消费者是最简单可靠的了，这不需要想了吧

或许也应该是期望位置序号和实际输出位置序号的均方差吧，实际值和排序结果没啥联系应该不可以用实际值来计算损失吧

迟早会跌下去，迟早会涨回来，你总会亏也总会赚，偶尔运气好一两次很正常，但是如何在无数次亏亏赚赚中综合起来还能是赚的就不是容易的了，市场行情好的时候以为自己是天才，行情不好的时候以为自己是傻叉，大家都会这样的，所以别那么激动

其实是不是想太多了，且不说同一个 menu 能被几个人操作啊，就算真的多现实情况下同时操作又有多大概率，直接加锁顶多慢几百毫秒而已，这真的不算个啥，还是别过度设计啊，如果并发冲突直接加锁超过 20%慢超过 5 秒以上，我觉得还有价值用 2 乐观锁加自动重试就行，否则除了增加不稳定因素和复杂度真的毫无优化的必要

如果是前端如果已经编译完成之后 docker build 镜像慢的话，我们之前发现个问题，就是一般 docker build 会在项目根目录执行，npm 安装后的 node_modules 也会在根目录，docker build 的时候好像会 copy 文件到 docker domen context ，看日志特点就是 docker build 启动花了非常长的时间，启动之后开发 build 很快就完成了，这个问题就是 node_modules 文件太多，所以可以试试把编译出的文件 copy 到一个单独的目录，然后 docker build 就可以快非常多了

如果也是用 docker 编译的话，其实可以把项目目录和 node_modules 映射进去，估计能快不少吧

而且吧官方文档写的是用 include ，没用在上面用 v-if 的吧

是不是 v-if 应该放在里边的 component 上，似乎实现的时候 keep-alive 内部一个属性保存了字组件来不销毁，v-if 在 keep-alive 上 keep-alive 都销毁重建了，那么估计保存的子组件也销毁了吧

@mengdodo #57 自然是每个项目启动的容器自己创建连接池了，数据库这边确实会连接数会高很多，但不是一个特别大的问题，而且换个方面来说每个容器的项目做的事情都少了，所以每个项目的连接数量也会低很多，虽然整提连接数量还是增长了，但也不是线性增长的，问题并不会特别严重

容器这边的话网络栈是独立的，所以连接数限制自然也是独立的，只是 k8s 连接集群外数据库的话需要走宿主机的 nat ，但是毕竟你宿主机的资源也不是无限的，实际也不大可能会超过宿主机的连接数量限制

如果你想说性能啥的话，没啥优势，大多数情况下其实是更差的，但这也不是个问题，云的优势本来也不在于性能好，云的优势自然是监控、备份和扩展了，你自己建就需要你自己搞监控告警、故障迁移、自动备份和扩展扩容了，云服务自然省的就是这些心了

有了 devops 工具、链路追踪、服务注册发现和容器化，微服务化后大大省事了吧，而且每个项目只负责一点点事情了，发布和测试也省心很多，分明是节省工作量的吧