之前似乎看到一篇文章尬吹这个项目的，好像还说 WebKit 的 JavaScriptCore 吊打 Chromium 的 V8 。现在 JSC 的性能如何我不知道，但是一开始谷歌开发 V8 不就是因为 JSC 性能不好吗？结果这么快就被反超了？
而且 WebKit 事实上已经是一个 Apple OS only 的项目了。目前 WebKit 官方并没有别的平台的，面向生产环境的产品，有也都是些非官方社区维护的项目(比如 WebKitGTK)，在别的平台上的稳定性如何得打个问号。而隔壁 V8 可是官方支持多个平台的。
最后还是生态问题，这个无需过多解释。

拆开？建议先从软件方面排查

应该现在就试试 Linux 有没有什么问题

个人认为防水只是噱头，因为真正因进水损坏了厂商并不会保修，实际防水性能存疑，不如买密封塑料袋

感觉是显卡的问题

HDMI 也有通过 RJ45 和双绞线传输的标准 HDBaseT

文档写得很详细哦 http://nginx.org/en/docs/http/ngx_http_referer_module.html#valid_referers

追求快速开发推荐嵌入 WebView ，跨平台也容易。追求原生、风格统一的话可以考虑 React Native for Windows 搭配 Xaml Island 嵌入程序内。React Native 的资料还是比较多的，开发起来也比直接写 Xaml 更快捷，学到的知识后续也可以用在别的平台的 React 开发上。

个人觉得不应该叫“四次挥手”，而应该叫“两端关闭”，这里的两端指的是两个发送数据的端。

曾经在网上看到一个问题，大概是想通过抓包得到的数据自己实现一个软件的通信协议，写完代码后发现服务器一直没有反应，而发送的数据并没区别。提问者在经过一番对比后发现：“为什么这个软件通信的时候，最后关闭连接只有两次挥手？”
最后发现客户端发完数据后要先关闭发送，服务器才会开始处理并回复。因为客户端已经关闭了，服务器最后关闭时看上去就只有“两次挥手”。

当理解了所谓 TCP 挥手其实是两端关闭后，楼主遇到的这个情况也就很好理解了：客户端先向服务器发送 FIN 请求关闭，服务器收到后回复 ACK 确认关闭，同时也附带 FIN 请求关闭，客户端收到后回复 ACK 确认关闭，此时两端都已关闭，就是断开连接了。

不是智能开关，是智能灯的话，那应该是灯的问题，联系售后看看吧。

JuiceSSH?

@lee88688 有呀，打印页面就有 Save as PDF

浏览器本身不是有导出 PDF 的选项吗？

扫 TCP 端口正确做法大概是用 raw socket 发个 SYN 包，没回应说明目标集资 down 了或者被防火墙过滤了，回应 SYN 则说明端口开着，回应 RST 说明端口关闭。
nmap 支持 SYN 检测，你觉得没用大概是扫描方法错了。

如果 nginx 本身不支持的话那大概是没有的，这种需求还是配合外部工具实现吧。

另外需要注意的是，Windows 商店安装的应用不一定是 UWP 应用，Win32 应用也能打包成 AppX 上架商店，或者 UWP 和 Win32 混合也是可以的。具体得看应用的权限列表里有没有“使用所有系统资源”(Uses all system resources)这一项。