electron渲染进程默认禁用fs模块是因安全沙箱设计，必须通过preload.js的contextbridge暴露ipc接口，由主进程校验路径白名单并调用系统命令执行权限修改。
Electron 渲染进程默认没有文件系统权限，fs 模块不可用，也不能直接调用 chmod、chown 等系统命令——这是设计使然，不是 bug。
为什么渲染进程不能直接访问 fs 模块？
Electron 的安全模型强制隔离渲染进程（Chromium）与 Node.js 运行时。即使你启用了 nodeIntegration，现代 Electron（≥12.0.0）也默认开启 contextIsolation，且 nodeIntegration 已被标记为不安全，生产环境必须禁用。
- 启用了
contextIsolation:true后，require('fs')在渲染进程里会直接报错：ReferenceError: require is not defined - 即使临时关闭
contextIsolation（不推荐），fs仍可能因沙箱（sandbox:true）被彻底禁用，触发Error: EACCES: permission denied - HTML 结构本身（比如
<input type="file">或拖拽区域）只提供路径选择能力，不自动赋予读写权限；选中的路径只是字符串，后续操作仍需主进程授权
如何让 HTML 页面“安全地”触发文件权限修改？
必须通过预加载脚本（preload.js）桥接，暴露最小必要接口，由主进程执行真实操作。
- 在
preload.js中用contextBridge.exposeInMainWorld暴露一个受控方法，例如：window.api.changeFilePermission - 该方法内部通过
ipcRenderer.invoke('change-permission', { path, mode })发起 IPC 请求 - 主进程监听
change-permission事件，校验path是否在白名单目录内（如用户文档目录、应用专属 data 目录），再调用fs.chmod或exec（Linux/macOS）/icacls（Windows） - 禁止暴露原始
fs或child_process接口；参数mode应做白名单校验（如只允许0o644、0o755）
不同操作系统对权限字段的处理差异
HTML 页面无法感知底层 OS 差异，但主进程必须适配：Unix-like 系统用八进制 mode（如 0o755），Windows 则依赖 ACL 工具或 fs.chmod 的有限支持（仅影响只读标志）。
- Linux/macOS：
fs.chmod(filePath, 0o600)可设读写权限；若需更细粒度（如设置 group/other 权限），需调用exec执行chmod命令 - Windows：
fs.chmod仅能切换readonly标志（0o444→ 只读，0o666→ 可写），无法控制用户/组/其他三类权限；真正修改 ACL 需调用icacls并解析其输出 - UOS/统信等国产系统：行为基本兼容 Linux，但部分发行版默认禁用
chmod对非 root 用户的某些操作，需提前检测并提示用户提权
容易被忽略的权限校验盲点
开发者常以为“路径合法 = 权限可改”，但实际还有几层隐性限制。
-
path是相对路径？必须用path.resolve()转为绝对路径，并用app.getPath('documents')等 API 限定作用域，防止路径穿越（如../../etc/shadow） - 目标文件是否被其他进程占用？
fs.chmod在 Windows 上可能抛出EBUSY，需捕获并友好提示 - 当前用户是否拥有父目录的写权限？修改子文件权限失败时，错误信息可能是
EACCES，但根源在上级目录权限不足 - Electron 应用是否以管理员/Root 权限启动？普通用户无法修改系统级路径（如
/usr/bin）的权限，这类请求应直接拒绝而非静默失败
跨端容器里的 HTML 结构只是交互入口，真正的权限决策和执行永远发生在主进程——而且必须带上下文校验、路径净化、OS 适配和错误兜底。漏掉任意一环，都可能把“功能实现”变成“安全后门”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
