nas不能当开发机用，因其缺乏本地浏览器进程、不支持热重载与调试、构建缓慢且权限混乱；唯一合理用途是资源存储与构建产物托管。
不能把NAS当开发机用，哪怕它装了Docker、开了Web Station、甚至连了键盘鼠标——HTML开发所需的实时反馈链路，在NAS上天然断裂。
NAS没有本地浏览器进程，所有“运行”都是假象
你在NAS上双击打开
index.html
- 它不会在NAS里渲染，因为NAS没浏览器进程；你看到的页面，实际是你的本地电脑浏览器加载了NAS共享目录里的文件（通过
file://或<code>http://NAS-IP/xxx） - 如果HTML里有
fetch('/api/data.json')，请求发向的是你本地网络环境，不是NAS——除非你额外配好反向代理、CORS、HTTPS证书，且确保路径全写对 - Live Server类插件根本起不来：VS Code插件依赖本地Node.js进程监听文件变更并热重载，而NAS上VS Code通常只是个远程编辑器前端，后端不在那儿
Node.js容器 ≠ 开发环境，只是部署靶场
你能在NAS上跑node server.js，但那只是验证服务端逻辑是否能启动，不是开发流程本身。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 编辑器无法连接容器内进程调试：
node --inspect端口映射后，VS Code Remote Debug需要宿主机网络可达+证书信任，NAS默认不满足 - npm install极慢：多数NAS用ARM芯片+eMMC或SATA SSD，
node_modules解压和符号链接创建耗时是x86 NVMe SSD的3–5倍，且容易因内存不足（ENOMEM）中断 - 类型检查卡死：TypeScript
tsc --watch在DSM/QTS的轻量Linux环境下常因/proc/sys/vm/max_map_count过低或cgroup内存限制被OOM killer干掉
Web Station静态托管只适合最终交付，不适合迭代开发
Synology Web Station或QNAP Qweb本质是Apache/Nginx精简版，连mod_rewrite都常被阉割，更别说支持ESM模块导入或Vite HMR。
-
import { foo } from './utils.js'会直接404：Web Station默认不处理Content-Type: application/javascript的MIME头，也不支持HTTP/2 Server Push - 改一行CSS就得手动刷新浏览器，没有HMR，没有source map，控制台报错定位不到原始行号
- 权限陷阱：上传后文件属主常变成
http用户，你SSH进去改代码，保存后Web Station因权限拒绝读取——得反复chown
真正能用NAS辅助开发的唯一方式：只做资源存储与构建产物托管
把NAS当网盘+CDN边缘节点用，开发动作全部留在本地机器上。
- 项目源码存在NAS SMB共享里，本地VS Code通过SMB挂载编辑（Windows需启用SMB 1.0兼容，macOS用
mount_smbfs） - CI流程走GitHub Actions：push后自动
npm run build，产物zip推送到NAS指定目录，Web Station自动指向该路径 - 用
rsync -avz --delete ./dist/ admin@nas:/volume1/web/myapp/替代FTP上传，避免遗漏.htaccess或缓存头配置
最易被忽略的一点：NAS的CPU调度策略默认偏向IO密集型任务，而前端构建（如Webpack、ESBuild）是典型的短时高CPU爆发负载，会被系统主动降级优先级——你看到的“构建变慢”，可能不是硬件差，而是ionice和renice值没调。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
