允许脚本写入文件和访问网络

一个爬虫脚本卡在第三步，允许原因是脚本目标网站返回了 403。你打开代码，写入发现请求头里缺了 User-Agent，文件问网补上之后还是和访 403。再查，允许发现对方检测了 TLS 指纹。脚本你换用 curl_cffi，写入问题解决。文件问网整个过程里，和访脚本没有往磁盘写任何东西，允许也没有建立外部网络连接——除了那次 HTTP 请求本身。脚本但如果你要把抓到的写入数据存下来，或者让脚本自动登录后再抓，文件问网那就绕不开两个能力：写文件和访问网络。和访

这两个权限在几乎所有主流语言里都是默认关闭的。Python 的 `open()` 能直接写文件，`requests.get()` 能直接发请求，看起来毫无阻拦。但浏览器里的 JavaScript 不行。你在 Chrome 控制台里执行 `fetch('https://example.com')`，如果目标域没有 CORS 头，请求会被拦截。想写文件？没有用户手动选择路径，`FileSystemWritableFileStream` 根本拿不到句柄。这种限制不是技术做不到，是设计时刻意加上去的。

我见过一个内部工具，用 Electron 写的，功能是批量下载报表并重命名后存到指定目录。开发阶段一切正常，打包后用户反馈“下载没反应”。查日志发现，渲染进程里的 `fs.writeFile` 被 Electron 的安全策略挡了。默认情况下，渲染进程没有 Node.js 集成，也就没有文件系统权限。开发者习惯了本地脚本的“想写就写”，忘了浏览器环境从第一天起就把这条路堵死了。

网络访问的情况类似。Node.js 里你可以 `net.connect` 到任意 IP 和端口，没人拦你。但浏览器里，`WebSocket` 只能连 ws/wss，`fetch` 受同源策略和 CORS 约束，`` 标签虽然能跨域加载，但无法读取像素数据——除非服务器给了 `crossOrigin` 属性且响应头允许。这些限制的出发点很明确：防止恶意脚本偷偷把用户数据传出去，或者往本地磁盘写垃圾。

那为什么还要“允许”脚本写文件和访问网络？因为自动化场景需要。一个定时备份脚本，要读数据库、生成 CSV、上传到 S3。一个监控工具，要定期请求健康检查接口，把结果追加到日志文件。这些任务用 shell 脚本也能做，但用 Python 或 Node 写更灵活。关键是，你得清楚权限边界在哪里。

Python 的 `os.chmod` 可以改文件权限，但改不了“脚本能不能写文件”这件事——那是由运行脚本的用户身份决定的。如果你用 root 跑脚本，它就能写 `/etc` 下的任何东西。用普通用户跑，就只能写自己家目录。网络访问也一样，防火墙规则、SELinux 策略、容器网络命名空间，这些才是真正的开关。语言层面的 API 只是暴露了能力，不决定权限。

我自己的习惯是：任何需要写文件或发网络请求的脚本，先在一个受限环境里跑。比如用 Docker 起一个容器，挂载一个临时目录，网络只开需要的出口。确认逻辑没问题，再放到真实环境。这样即使脚本有 bug，也不会把宿主机搞乱。有一次一个日志轮转脚本写错了路径，因为容器里只有 `/tmp` 可写，它老老实实报错退出，没造成任何破坏。

反过来，如果你在本地直接跑一个从网上抄来的脚本，它里面有 `os.system('rm -rf /')` 或者往 `~/.ssh/authorized_keys` 写东西，你根本不知道。权限这东西，给出去容易，收回来难。所以我的判断很简单：脚本可以写文件，但只能写它该写的那几个路径；可以访问网络，但只能连它该连的那几个域名。多一个都不行。