命令行

要精通的话会稍微困难一些，官方文档过一遍，30 天足够了！ https://go.dev/doc/

有啊，官方的教程，从 Hello World 开始，30 分钟学会足够了！ https://go.dev/tour/

@ezrameow #6 PAC 里应该是不支持请求接口的，这个应该是需要立即同步返回的。

@magese #8 每次请求前都更新的话，你访问页面的速度就会非常慢了。建议是改成 1 分钟或 30 秒后台自动更新一次。
这个应该没有现成的扩展了，像 #7 那样自己写个扩展很快的，或者 SwitchyOmega 是开源的（商店上有 GitHub 地址），clone 下来自己改更新频率也行。

@whileFalse 差评 chrome 不支持生成更长的密码？同时差评 baidu 不支持更长密码……
chrome 管理密码的话，iOS 是可以直接在应用中自动填充的，只要装了手机 Chrome 并自动同步，系统设置里的密码选项里就可以选择自动填充 Chrome 记住的密码。

关键词：PAC （ Proxy auto config ），然后用 SwitchyOmega 就行。
前提是把你的接口返回改掉，不是返回 JSON 了，而是返回一个 PAC 文件（就是个 JS 文件）。

@dingwen07 这个不支持 IPv6……

@ddllzz #4 看这个截图，你 gst 后的输出就显示了这些文件都发生了变更，运行 git diff 看一下具体的变更内容再做判断。
另外，你 ga 之后应该只添加了一个文件，但是 gcmsg 之后看起来是提交了多个文件。请在 ga 之后 gst 看看是不是只有一个文件变绿了？
另外，我还注意到，你 gst 之后打印的文件列表和 gcmsg 之后打印的文件列表对应不上，确认一下你的 gcmsg 都执行了什么操作？

建议不要使用 alias ，使用原始 git 并禁用 hooks 看看是否还有问题：
gst => git status
ga xxx => git add xxx
gcmsg "xxx" => git commit --no-verify -m "xxx"
（加 no-verify 是用来禁用 hooks 的）

@lululau 楼上说的“时间戳”根据语境，应该特指的是“unix 时间戳”，也就是用整数来表示 UTC 时区 1970 年 1 月 1 日 0 点 0 分 0 秒开始的秒数（有些编程语言是毫秒数）……
而“时间戳”本身就是描述一个具体时间的抽象概念，具体是拿 int 来描述、拿 string 来描述、甚至拿 bitmaps 来描述都可以的。

存储时间一定得考虑时区，即使你现在还遇不到时区的问题，但未来总会遇到，遇到就是 bug 。

所以只要使用带时区信息的方式存，就绝对没问题。通常这两种带时区的方案用的比较多：
1 ，使用 unix 时间戳 / 数字时间戳，时区信息是带在<定义>里的，固定 UTC 时区，存的时候转成 UTC 时间存，读的时候根据需要转成对应时区来显示。本身 unix 时间戳是表示秒数的，部分编程语言实现为整型的毫秒数，或者以小数的形式带上毫秒信息，就统一叫做数字时间戳了。
2 ，使用标准的 RFC 3339 ，这是 ISO 8601 的一个固定格式变体（存储的时候不建议使用宽泛的 ISO 8601 ，带了很多没必要的东西。读取显示的时候到无所谓），这个时间格式里是带着时区信息的，Z 结尾表示 UTC 时区，当然也可以存成其他方便阅读的时区。

通常建议是存成整数数字时间戳，因为对计算机来说，整数是最高效的，进行时间比较也是最方便的，占用空间也是最小的。而在需要人阅读的时候，根据需要转换为阅读者所在时区的 RFC3339 / ISO 8601 字符串来显示。

@ttimasdf #23 ？？？你用过 Linux 吗？还就“一部分”编程语言的 IDE 比较健全？还“太自闭了”，我看是你自己太自闭了吧！
光我日常使用的软件（不提那些拿 Electron 浏览器套壳的软件了）：
浏览器，Chrome 和 Firefox 都有功能完整的原生 Linux 版本。
WPS Office 也有完整的原生 Linux 版本（更新频率很低，但目测还在更新）。另外也有 LibreOffice ，这个没怎么用过，不评价。
聊天 IM 的 Telegram 也是功能完整的原生 Linux 版本。
玩游戏 steam 客户端也是原生 Linux 版本的（一直保持更新，只不过是 32 位软件，要装 multilib 支持库），同样 Nvidia 和 AMD 的显卡也有官方 /非官方 Linux 的驱动，Dota2 、CS:GO 都是原生 Linux 版本。
视频播放有 VLC ，也是功能完整的原生 Linux 版本。
听音乐有网易云，这个功能完善度差不多 80%，也是原生 Linux 版本。
其他稍大一点的软件，直播录像有 OBS Studio ，图像处理有 GIMP ，3D 建模有 blender ，视频剪辑有 DaVinci Resolve 、网络抓包有 Wireshark……这些都是功能完整的原生 Linux 版本。

令：开源软件不是世界主宰，但 Linux 下的软件也没有人要求你一定要去开源。闭源发二进制包的软件也是有一大堆。

@Austaras 图片用 base64 的话，文件体积会变大 1/3 ，并且代码量都比 FormData 要多了……还不如直接用 FormData 来的简单，并且用 FormData 只会固定大几个字节。

@NathanDo 你这是故意把代码写复杂了，如果使用原生的 fetch ，相比 application/json ，application/x-www-form-urlencoded 会更简单：
```
fetch('/', {
method: 'POST',
headers:{
'content-type': 'application/json',
},
body: JSON.stringify({
a: 1,
b: 2,
}),
})
```
对比
```
fetch('/', {
method: 'POST',
body: new URLSearchParams({
a: 1,
b: 2,
}),
})
```
原因是浏览器默认网络请求都不认识 json 的，不指定 header 的话都默认 text/plain （如果 body 指定对象的话会自动 toString 变成 [object Object]），而 URLSearchParams 的构造函数就支持直接传对象，并且直接提交自动设置正确的请求头 application/x-www-form-urlencoded 。

@yaphets666 至于 FormData ，通常只会在上传文件的时候才会用（由于设计原因，平常用有点浪费网络资源，弱网环境影响体验）。而上传文件的话，你就要有个文件来源，一般是写一个 form 里带一个 input type="file"，而 FormData 天生就为这个场景设计，只要 getElementById 拿到 form 对象，直接传给构造函数 new FormData(form) 就可以了。
同样代码也很简单，也会自动设置正确的请求头 multipart/form-data; boundary=xxx：
```
fetch('/', {
method: 'POST',
body: new FormData(document.getElementById('form')),
})
```

[当然，如果使用的是第三方的网络请求库的话，那应该是 JSON/x-www-form-urlencoded/form-data 站在同等地位啊，具体走什么都取决于封装而已。]

另：我用的不是默认的 3389 ，而是高位端口。
所以说，改端口啥的感觉基本没用，扫一遍端口，发几个探测包就知道对应服务了……