HTTPS 流量只能看到域信息，路径、Query、Header、Body、Method 全部加密，所以中间人完全不可能知道这个流量传的是图片还是文字还是其他的东西。这恰好也是 HTTPS 的设计初衷。

想要让中间人能分析流量内容，有两种思路：
1. 代理，客户端装代理服务器的 TLS 证书，发请求走代理服务器代理，代理服务器用自己的私钥解密流量，分析完之后再用目标服务器的 TLS 证书加密，转发给目标服务器，返回的时候也是在代理服务器解密，分析完后再用代理服务器的私钥加密返回给客户端。这个方案对页面依赖的其他资源兼容性好，但是操作起来稍微有点麻烦。
2. 镜像站，客户端请求镜像站的域，HTTPS 用镜像站的 TLS 证书；镜像站分析完后重新用目标网站的 TLS 证书建立 HTTPS 转发给目标网站，返回数据的时候也是先返回镜像站，分析完后用镜像站的私钥返回给客户端。这个方案操作起来简单，兼容性欠佳，一不小心还可能会跳转到目标网站的域上。

gmtToBeijingTime

或者通用一些的 Stirng convertTimeZone(String fromTime, int fromZone, int toZone)

一般来说 Intel>Nvidia>AMD。

Intel 通常是 Kernel 自带驱动，最稳妥的方案，当然性能有限； Nvidia 开源驱动质量也还行，就是最新的卡可能需要等一段时间才能支持； AMD 近几年没用过，不过网上经常说兼容问题比较多。

如果软件对 Wayland 兼容性好的话用 Wayland 取代 Xorg 动画效果啥的可能可以更流畅一些。

当然，具体的硬件搭配、Kernel、驱动、配置可能导致不同的结果，还是要自己试试。

尝试过树莓派 3B，相信我，完全达不到要求。

GitLab 如果只是存储 Git repo 的话，推荐 Gogs，GitLab 对性能要求很高亲测在下面的方案跑不动。

我自己是买华擎的板载 CPU 的主板，J5005 J4105 J4005 都可以，板载 CPU 有 Intel 的核显，HDMI 接电视性能足够看 4K，TDP 10W 省电，然后用迎广的 4 盘位机箱（ J 系列板子最多 4 个 Sata 口，用 Pcie 转 Sata 的转接卡可以再扩展 1-2 个），系统装 OMV(Debian)，系统直接装在 16-32G 的 U 盘长期插在背面（ OMV 里有扩展可以优化日志写入，提升节省闪存寿命，怕 U 盘挂掉还可以装个定时备份系统镜像的插件，拷出来写个新 U 盘插上继续用），装个 Docker 扩展，然后 Gogs、Pi-hole、Wiki 等等的都可以用 Docker 来跑，存储部分不推荐 RAID-5 （想知道为什么可以去网上搜），我自己是用 Snapraid （需要自己写定时任务更新校验盘）+MergerFS （把多个硬盘分区虚拟成一个分区）。

不算硬盘的话整体下来 2000 左右（半年前的价格），比群辉性能高，还便宜，要是喜欢群辉也可以装黑群晖，CPU 是 x86 架构的跑软件没有兼容问题。

这是个特别宽泛的问题，不是由一个因素决定的，是由多个方面的因素决定的。

维护者是谁？
JavaScript 语言本身实际上是以引擎的形态存在的，而引擎是由各个厂商依照自己的具体商业或非商业的需求来研发的，统一参照的 ECMA-262 标准来设计的，ECMA-262 是 ECMA 组织的 TC39 委员会主导制定的，这个委员会的成员中一部分是引擎厂商的技术人员，由于 JavaScript 主要用于 Web 技术领域，所以其中还有一些参与制定 Web 标准的人；此外 ES-262 接受非 TC39 成员为制定规范提出草案，这些人也算是 JavaScript 的维护者。
所有维护者中，有些是直接利益关系者，有些是间接利益关系者，有些是公益人士，也有些是独立爱好者。整体社区算是非常开放和活跃的。

为什么是它？
最一开始 Web 技术出现的时候，JavaScript 就是为了 Web 而设计的，并在当时因为种种原因在多种语言中脱颖而出，成为最广泛使用的 Web 开放语言，感兴趣可以了解一下这段历史。
为什么现在依然是它，这是由市场决定的。绝大多数用户使用的浏览器都以 JavaScript 作为页面的主要开发语言，绝大多数的 Web 开发者也都用 JavaScript （或最终编译成 JavaScript 的其他语言）作为页面开发的主要语言，浏览器、Web 相关技术沉淀和标准都是围绕 JavaScript 的；那么现在有一个新的厂商想做一款新的浏览器，如果不用 JavaScript 作为主要语言的话，就会难以拉拢现有的 Web 开发者加入，也会因为没有专门的技术沉淀以及标准的支持而难以发展。

它的设计目标是什么？
最初是为 Web 设计的，所以它的设计目标要以当时的 Web 技术的行业状况来看。

> 网景预见到网络需要变得更动态。公司的创始人马克·安德森认为 HTML 需要一种胶水语言，让网页设计师和兼职程序员可以很容易地使用它来组装图片和插件之类的组件，且代码可以直接编写在网页标记中。
> 1995 年，网景招募了布兰登·艾克，目标是把 Scheme 语言嵌入到 Netscape Navigator 浏览器当中。但更早之前，网景已经跟昇阳合作在 Netscape Navigator 中支持 Java，这时网景内部产生激烈的争论。后来网景决定发明一种与 Java 搭配使用的辅助脚本语言并且语法上有些类似，这个决策导致排除了采用现有的语言，例如 Perl、Python、Tcl 或 Scheme。

——维基百科《 JavaScript 》

提炼一下就是：
1. 要能实现较复杂的逻辑来拼接 HTML。
2. 能在浏览器上和 HTML 配合使用。
3. 需要被快速设计和实现出来（迫于网景内部争论，当时仅仅花了 10 天就被设计出来了）。
4. 蹭 Java 的热度，有必要也可以借鉴 Java 的一些好的设计。
5. 尽量贴近当时人们对编程语言的认知和习惯，同时不要像当时很多语言那么复杂，易学易用便于推广。

它和其他语言相比，到底有什么不可替代的优势？
没有什么语言是不可替代的，就看在应用场景上最看看重什么。我举个例子，现在有一些非网页技术也想使用 JavaScript，原因可能是因为 JavaScript 开发者数量众多，自己的技术便于推广，比如 Electron 技术可以用 JavaScript 来开发桌面软件，招 C\C++工程师肯定不如招 JavaScript 工程师容易，那么对于一些并不需要系统底层功能支持的桌面软件来说，用 JavaScript 性价比很高，特别是对于那些原本就有网站产品的公司（本来就有 JavaScript 开发资源）。

1. 不要讨论国王。
2. 关注登革热疫情，防蚊，可以在 7-11 买到当地人用的那种防蚊喷雾，很便宜，非常有效。
3. 防晒，推荐防晒等级高的防晒喷雾，当地也有卖。
4. 特产不一定便宜，主要是看是否明面上都针对游客，当地人往往有自己的购买渠道，建议多逛些地方了解价格，有的时候在 B 城市卖的 A 城市特产比在 A 城市的商场买还便宜。
5. 大众点评普及率很高，但是刷评价的情况非常常见，可以和 Tripadvisor 对比着看。
6. 只要没有收费标准或明码标价的，就都试着了解一下行情讲讲价，也遇到过突突车、双条车宰客的情况。
7. 我 2018 年在清迈入境，办理入境手续的时候那边明确说禁止给小费。
8. 建议护照在国内找正规大型旅社提前办好，虽说有落地签，但是需要排队。
9. 接送机、包车都可以在淘宝上找。
10. 可以提前在国内买泰国旅游手机卡，进入泰国后装入手机开机激活，注意套餐到期前续订套餐，因为到期后非套餐资费比较坑。
11. 曼谷拉差达火车夜市可以去看一看，旁边的停车场走到高处可以拍到俯视全景。
12. 泰国适合慢节奏旅游，建议选比较好的酒店，一个地方多待几天，行程不要安排太满。
13. 据说远离河流两岸，那边基本都是贫民窟，脏乱差。
14. 去皇宫参观之前先了解一下皇宫内部开放情况，因为经常会有部分区域维护无法参观。
15. 去庄重的地方，如皇家区域、寺庙等，无论男女都穿长袖长裤，可以常在保利备着。
16. 去寺庙的话请仔细研究寺庙礼仪。
17. 了解一下哪些情况可以退税，以及如何退，注意提前到达机场为离境办理退税或免税提货预留多些时间。
18. 免税店买的免税产品有两种，一种是当场退税，买完后可以直接随身带走；另一种是机场退税，买完后免税店帮你送到特定机场，你在机场离境的时候取。可以提前了解免税店的优惠券可以在哪里获得，以及如何使用。
19. 燕窝，据说只有特定形态的燕窝产品才允许带回国，请提前了解。
20. 泰国产榴莲，但是泰国人和我们一样也不是都喜欢榴莲，酒店等一些场所禁止带榴莲，请提前了解。
21. 护照和签证随身带，可以多复印几份放在各个行李中，一旦原件丢失据说复印件可以省去很多麻烦。
22. 提前记好警察和中国使馆的联系方式 http://www.chinaembassy.or.th/chn/sgxw/t1647846.htm

一楼是正解，如果不明白的话建议研究一下 HTTPS 加密的原理。

大体方案就是：
1. Client 上安装抓包软件附带的抓包用 HTTPS 证书，这个证书优先级很高，以至于 Client 的任何 HTTPS 通信都会优先使用这个证书。
2. Client 上配置抓包软件的代理地址，让 Client 发任何网路请求都优先发到抓包软件上。
3. 抓包，就能直接看到数据包解密后的内容了。

如果实在系统开发方面的话，强烈推荐 Rust。
想做服务的话可以学 Go。
然后 C/C++也不要扔，系统开发就属 C/C++轮子多，有需要随时可以直接用在 Rust 或 Go 上。

刺客信条第二代 Ezio 三部曲，其他的没玩过，所以不清楚是不是一样的。
育碧基本上复刻了一个 19 世纪的佛罗伦萨、威尼斯、罗马，走到一些名胜古迹（比如罗马角斗场和圣母百花大教堂）或一些有历史代表性的人或物（比如带着乌鸦面具的医生），可以按 Tab 键出详细的介绍，配上不错的游戏性、优化和卓越的音乐，带来非常棒的旅游感受。

喜欢兜风可以玩 GTA，从圣安地列斯到 4、5 都可以一边开车一边听音乐一边看着夕阳下的风景。

显卡强悍的话可以试试折腾一下 Minecraft+Optifine+第三方 Shader+拟真材质。

可以试试多买几站，举例，K51，天津西到费县：
买提前几站上车的票，比如买北京到费县的票，然后在天津西上车，这种规定上是可以的，不过最好先打个 12306 问一下，就说赶不到北京能不能在天津西上车；
买晚几站下车的票，比如买天津西到临沂的票，然后在费县提前下车；
或者上车站和下车站都超范围的，比如北京到临沂的，然后从天津西上从费县下；
还有最差的一种就是买天津西上车的、费县之前下车的，上车之后做过站补到费县的票。

当然高铁用这些花样肯定损失的钱会比较多，而且因为站点密度小，可操作性差一些。

没有应用场景谈对错是没有意义的。

用于字典（映射）的话选 A （其实没必要放数组里了）；比如需要频繁地按照 IP 地址来取相关信息，此时用 A 方案能避免大量的循环语句。
用于呈现对象列表的话选 B ；比如返回一个服务器列表，迭代对列表里的每一台机器的信息做相应的处理。

两种我都经常用，没有啥绝对对和绝对错的，哪种合适就用哪种。

C++学习曲线太陡峭，只是想做游戏服务端的话可以从 Java、Go、Node.js 入手，有时间也可以看看 Rust。

另外不考虑换流行一些的技术栈继续做 Web 后端嘛？这样以前在 Web 后端积累的经验还能用上。

公司里用的技术大多数都没有中文文档，还要偶尔和全球开发者讨论一些问题，大学的时候 CET-4 考了 3 次都没过的我，工作后被逼得读各种英文文档。
从一开始一周看完一篇英文文档，到最终每天可以看多篇英文文档，我花了 3 年的时间。

计算机技术是国际化程度最高的领域，而英语是国际化必备的工具，所以个人觉得要想获得第一手技术信息，还是要学好英语。

2014 年的时候跑过一年，用 Titan X 级别的算力跑到了国内前 100，后来发现电费感人，就不跑了。
当时跑的都是生化医疗类的项目，比如对抗艾滋病 疟疾和癌症。

aria2，本身支持直接下载和 BT 下载，用 Motrix 之类的工具可以将迅雷链接转成 BT，再加一些其他工具可以实现百度网盘的下载。

我开发基本上都在 Linux 上，想用什么软件包直接一条指令安装（特别是有 AUR，基本上什么都能装），在 Windows 上直接配置通常就比较麻烦（我是搞 Web 全栈开发的）。

微信可以用 wine 版本的，或者网页版也可以临时用用； QQ 前段时间说重新退出 Linux 版了；迅雷和百度网盘都可以用 Aria2 解决；公司用的 Office365 是全网页版的（包括 OneNote，不过我不怎么用）；邮箱可以用网页版也可用 Thunderbird 或桌面自带的 Mail 配置 Exchange ；文档、笔记个人还是比较习惯用 Keep、石墨、腾讯文档，这些要么没出客户端，要么网页比客户端体验好。

现在在家里常年是 Win10 + Manjaro 双系统，在公司是 Mac OS，Win10 就只用来玩游戏，然而现在随着 Pop!_OS 之类的系统的出现，在 Linux 上玩游戏的体验在逐渐变好。

WSL1 不是完整的 Linux 系统，比如 Systemd 就用不了，以及也没法在 WSL 下跑 Docker ； WSL2 是基于 Hyper-V 虚拟机的，也就是说会占用虚拟化接口，没法同时跑其他虚拟机软件。

个人体验来说，在开发层面基本上就是面向微软平台的开发是 Windows 占优势（比如 PC 游戏），移动平台开发是 Mac OS 上体验最好(当然有一半 iOS 独占的原因)，服务和大型前端开发还是 Linux 上最便捷（ Mac OS 除了软件包依赖会有点折腾以外也还不错）。

技术选型讲究没有最好的，只有最适合的。个人认为各家取其长就挺好的。