openvpn/TLSVPN over proxy 就行了

@firejoke
常见的系统内核都被人研究的比较透彻了，所以这些内核提供的资源调度方式都是比较好预期的。

以调度的眼光来看，一个耗时任务所需要的 CPU 时间是无穷大的（因为无法预知具体需要多少时间来完成任务），而 CPU 时间显然是有限的。
对 Windows 来说，Windows 会优先保证在调度周期内每个线程都能得到一定时间的执行的机会，在此基础上，剩余的时间按照优先级分配给各个线程。也就是说，进程优先级实际上保证的也是任务在系统中所占用的时间比例。
我不知道所谓低优先级任务启动时不能让出 CPU 时间是一个什么概念，但是我十分确定，在高优先级线程需要 CPU 时间时，对比低优先级线程高优先级线程会获得更多的 CPU 时间。
在 Windows 中，还可以给进程设置 JOBOBJECT_CPU_RATE_CONTROL_INFORMATION ，可以设定 JOB 中进程使用的 CPU 占比或者时间，可以设定为动态比值，也可以设定绝对周期。这样可以比较好的控制 CPU 时间的分配。

最后资源调度本来就是内核的活，用户态根本拿不到准确的数据来进行调度。
如果内核提供的优先级+CPU 时间限制还满足不了你的需求，那你可能需要的是自己定制一个系统内核。

@firejoke
只是为了系统空闲的时候能使用 CPU 资源，忙的时候不要占用的话，Windows 下面直接设置进程优先级就行了。

设置进程优先级为最低，这样 Windows 会尽可能的调度其他进程，只有空闲的时候才会把 CPU 时间交给低优先级进程。

给管理员权限就应该视为你授权了对方做任何操作。
所谓完全独立的账户在系统层面是不存在的。
如果只是临时用用，可以考虑影子系统或者 UWF 一类的方案，这样重启后就还原了任何更改。

windows 下面直接设置 job 就可以限制 cpu 使用了。

inline 编译器要求随时能找到代码，不然怎么给你内联进去。

查了一下，说错了，更正一下：
operator delete[] 是有的，并且可以重载。

另外 double* 不一定是占用 4 字节，比如 X64 下面就是 8 字节。

没有 double[] 的析构函数这种玩意。
对于内置类型 delete 和 delete [] 的行为没有区别，都是直接释放内存。
如果是 class 类型，delete [] 会调用数组里每个元素的析构函数，然后再释放内存。

@zhangjinghua
未定义行为的结果就不要纠结了。

我自己实测结果：VS2022
编译位 X86 不加 stdlib.h 运行调试都没问题
如果编译为 X64 不加的情况下调试就会弹错误了。

最新的 MSVC 其实有弹警告，你可能没注意到。

warning C4013: “malloc”未定义；假设外部返回 int

根据提示我猜测：
编译器没找到 malloc 的定义，然后默认返回的 int* 为 int 。
然后链接器是正常 link 到了 malloc 上，在 32 位下面这样是没问题的，但如果编译 64 位的程序返回的 int* 本来是占 8 字节但是编译器强行截断成了 4 字节的 int 在赋值给 int* 所以地址就不对了。

多方面的原因导致的这个结果。

该内存不能为 read/write 这个提示大多数时候是程序自己因为各种原因内存读写越界了。
一个是新版本的 C/CPP 编译器对这种内存越界的错误做了更多的检测和防范，比如 VS2005 开始就提供了 strcpy_s 一类的函数，如果内存有越界调试阶段就更容易检测到（因为会弹 CRT Error ）。
注：（ XP 的下一代 Vista 是 2006 年发布的）

另一方面，Vista 开始使用了新的 NT 6 内核（ XP 是 NT 5 ），新内核做了更多的安全限制。
比如：XP 上经常会有 DLL 想办法插入其他进程，但是 Vista 以后同样是管理员权限的用户在开启 UAC 的情况下非管理员权限的进程就没办法向管理员权限的进程插 DLL 。
这些安全限制虽然不是直接避免了这个问题，但是开发人员乱插 DLL ，乱搞系统内核的风气确实是有一定程度的遏制。

最后一方面是，新的系统对于这类问题不再是单单的给弹不能 read 之类的错误，而是告诉你程序崩溃了。（根本上取消了这个提示）

不要纠结这些标准库函数内部怎么实现的，看你换个编译器，甚至换个版本就会变了。

@alexkkaa
现在银行一般情况下是不给 U 盾这种东西了，原因是断卡行动。
银行的安全措施本身是比大部分 app 要做得好的，认为银行不安全是一种错觉。
指纹，手势密码一类的只是为了方便用户在常用机器上的快速登陆，换设备就没法用了，而且用户可以选择不要启用。
手机验证码是不够安全的，我是支持 U 盾一类安全措施的，只不过大众不能接受。
至于 POS 机盗刷是没必要担心的，现在的芯片卡本身也没办法复制，卡片本身就是一个很好的物理介质了，所以卡片+密码的安全性是没有问题的。

回到主题：
楼主遇到的问题主要是运营商的问题，建议是去运营商处理一下，手机卡什么的补一下，预留信息更新一下，服务密码改一改。

楼主要害怕其实可以直接所有钱转到一个银行，然后直接电话银行客服挂失或者冻结，这样不到银行柜台谁也动不了这些钱了（手动狗头）。
不过运营商的根本问题没解决还是有风险的，毕竟还可以尝试给你借网贷一类的操作，所以还是尽早去运营商营业厅处理。

后台 URL 和密码改一下就行了。

你问我相信不相信会上传，我相信是会的。只不过这件事情是没办法证明的，只能说怕就不要用。

就算你抓包实际上也没办法证明什么。抓包本身对于 TLS 一类的加密连接也看不到具体是上传了什么内容，而且就算现在没有上传，也不能保证以后不会上传。毕竟上传这件事情就算现在没做，想做的话一个固件更新或者一个远程配置就可以做到。

不要混用普通指针和智能指针 p413
这个只是一个建议，并不是一个不可打破的规则。混用本身没有问题，只是你得知道自己在做什么。

shared_ptr 是内部帮你维护了一个引用计数， 通过引用计数来确保内存不再被引用的时候就释放。而在使用过程中如果使用 get() 或者直接使用原始指针并不改变引用计数，这是需要自己注意的。

1 、我认为书中的表达是没有说错的，是你理解出现了偏差。
原书中的意思是只有 vector 还在生存周期的时候这些元素才能正常访问，如果 vector 销毁，则其中的元素应该被认为已经被销毁了。

2 、书中的描述很明确。如果你使用 get()拿到了原始指针，并且拿原始指针初始化了另一个智能指针，在第二个智能指针退出生命周期的时候内存已经被 delete 过一次了。使用已经被 delete 过的内存是一种未定义的行为，也许编译器在处理上并没有重新使用这段内存空间，所以你仍然能访问得到原始的结果，但是这只是一种巧合（偶然），并非一定会发生的事件。

最后友情提示：发帖请注意排版