Hello, world! 一个新域名，一个新开始！这里是low-key.cn，一个很低调的web前端程序员的工作经验分享博客。

首先，自我介绍一下：我的网名是Dr490n，目前在福州某个私企做web前端开发工作。狠低调的前端是本站的名称，也是我更新工作经验相关内容时使用的ID。

这个新域名low-key就是低调两个字的英文。也体现了这个网站的特色，简单、低调……但所有的内容都是本人整理出来的工作经验！就算是转载别人的内容，我也会根据自己的理解作出一些修改。添加一些我认为有意义的拓展，或者改掉一些冗余的描述。我希望这里的文章可以在对应知识点上直击痛处，让各位读者有醍醐灌顶之感。

搭建这个网站的契机

其实，这个网站已经存在十几年的时间了，之前的域名dr490n.cn我准备转成自己的生活日常分享，所以才把这个工作经验分享博客转到了这个域名。
要说这个网站的契机，就是工作的过程中我搜索过很多项目上需要的知识碎片，如果不找个地方整理成自己的内容，过一段时间之后就会忘记掉。而再次搜索时，可能之前留意过的网站已经无法访问了，只剩一堆图片报错、代码格式混乱的转载版本。
别看这个网站目前公开的文章还不多，我有很多知识碎片都是存成草稿的。就是太零碎了，感觉不做好解释发出来有点雨里雾里。等有空补好一下上下文才会发。所以，各位可能看到新的文章出现在某个过去的归档中，别见怪！那个创建时间是收集到这个知识点的时间，既然能发出来就说明在目前的环境下，这条经验还可以用。

比如，nodejs的LTS现在已经更新到22.11，但很多的项目还是基于14-18的版本搭建的。如果不注明这个经验适用于14-18左右的版本，很多人就会以为对所有版本都适用，就误入死胡同了。但现在网络上很多博客分享的经验都不会解释环境问题的……我提取的知识就必须在各种可能环境里面验证一遍，至少确认几个可以正常执行的版本，才会把这条经验分享出来。

最后，感谢各位对这个新网站的支持！希望各位都能在这个网站上收获需要的知识！共同进步！

从Electron版本12.0.1开始，BrowserWindow默认的webPreferences配置里contextIsolation的默认值从false改成true了。先看看这个参数的描述：

是否在独立 JavaScript 环境中运行 Electron API和指定的 preload 脚本. 默认为 true。preload 脚本所运行的上下文环境只能访问其自身专用的 document 和global window，其自身一系列内置的JavaScript (Array, Object, JSON等等) 也是如此，这些对于已加载的内容都是不可见的。 Electron API 将只在 preload 脚本中可用，在已加载页面中不可用。 这个选项应被用于加载可能不被信任的远程内容时来确保加载的内容无法篡改 preload 脚本和任何正在使用的Electron API。 该选项使用的是与Chrome内容脚本相同的技术。 你可以在开发者工具Console选项卡内顶部组合框中选择 ‘Electron Isolated Context’条目来访问这个上下文。

把文档里面翻译成中文的内容适当改回来之后，应该容易理解吧？就是 contextIsolation = true 时你预加载的 preload 脚本和窗口加载的第三方网站内容是两个隔离的 window 对象， preload 脚本没办法访问第三方网站页面里的全局window对象！

当然这个修改对 <webview> 标签也是生效的，但因为Eelecton本身不鼓励使用 <webview> 标签的关系，文档里面没有明显的提示。如果你也遇到升级Electron版本后 <webview> 标签用的 preload 读取不到第三方页面的全局 window 对象的问题。可以在 <webview> 标签增加上webpreferences这个属性：

1
2
3

<webview id="viewFrame" ref="webview" :src="pageUrl" :preload="preload" :useragent="userAgent" :partition="partition"></webview>
<!-- 改成 -->
<webview id="viewFrame" ref="webview" :src="pageUrl" :preload="preload" :useragent="userAgent" :partition="partition" webpreferences="allowRunningInsecureContent, contextIsolation=0" disablewebsecurity></webview>

这样旧版的preload脚本就能正常的在 <webview> 里面执行了！

发现问题

今天准备测试一些PHP脚本，于是打开了久违的XMAPP环境。
但是XMAPP环境并没有像以往的那样正常地启动起来，而是在日志区域显示了这样的一段提示：

XMAPP环境无法启动，红色提示说80口被PID为4的进程占用。

然后我看了下Netstat的记录，确实是被PID为4的进程占用了：

说明一下netstat的指令：
我使用的指令是netstat -ano，其中：
-a是显示所有连接和监听端口；
-n是以数字IP地址的方式显示地址和端口号，如果不写这一项会看到“外部地址”一列有的会显示为域名或主机名；
-o是显示连接对应进程的ID
所以，要查明对应关系，必须至少输入“netstat -ao”。
当然，如果你发现列表太长找不到你要找的80口数据，你可以附加一个处理字符串的“|findstr 80”就可以精确定位出几条80口的连接记录了。

解决方法

遇到这种情况，首先要确定占用进程是哪个。
我们用到的是每个电脑都有的软件——“Windows任务管理器”。

什么？你不知道怎么打开“任务管理器”？
……同时按住Ctrl+Alt+Delete，就能看到“启动任务管理器”的选项（Win 7）或者直接打开了“任务管理器”（Windows XP）。
……或者在任务栏上面打开右键菜单也能找到“启动任务管理器”选项。

将“任务管理器”切换到“进程”面板，查找一下PID为4的进程。一般显示的都是System。这是一个系统进程，使用右下角的“结束进程”没有办法关闭这个进程。

如果你的“Windows任务管理器”里面看不到“PID”一列，你可以将其显示出来。方法如下：

• 打开“查看”菜单，点击“选择列…”菜单项。
  
• 在打开的新窗口中勾选“PID”一行，点击“确定”即可。
  

遇到这种情况就只能重启么？不，不一定！

可以去看下你最近安装的服务，将他们关闭一下试试看！

比如说：
我前段时间为了测试IIS下面的伪静态路由，在这部Windows 7下面安装了IIS套件。而这个套件的万维网服务（W3SVC）也是隐藏在System进程中占用80口的罪魁祸首。

在Win XP中IIS相关的服务都是使用独立的inetinfo.exe进程，比较容易看出是IIS在占用，
而到了我使用的Win 7的时候，IIS服务的启动指令已经变成了
C:\\Windows\\system32\\svchost.exe -k iissvcs
这个“Windows服务主进程”的模式来运行，这个时候看到的监听端口的进程很有可能被显示成System。

这时候，只要关闭对应的服务就能释放出被监听的80端口了。

打开“服务”管理页的方法：

• “计算机”（或者“我的电脑”）右键菜单选择“管理”打开的窗口中展开左侧树的“服务和应用程序”节点，找到“服务”一项。
• “控制面板”里面找到“系统和安全”（如果显示的是分类界面）里的“管理工具”，双击“服务”快捷方式打开。
• 打开“开始”菜单，选择“运行…”，然后输入“services.msc”即可打开。

当然，并不是所有人都像我这样被IIS这样“愚蠢”的占用问题折腾地到处搜索答案。除了IIS以外，我搜索到的情况中有人是被SQL Server 2008中的报表服务所占用的。
所以，别因为多次重启后80口还是被占用而准备重装系统，很有可能是一些你前些时间安装的服务搞的鬼。