点赞 + 关注 + 收藏 = 学会了

整理了一个n8n小专栏，有兴趣的工友可以关注一下 👉 《n8n修炼手册》

不管是在电脑还是 NAS 通过 Docker 部署 n8n，环境变量没配置好的话，使用 Read/Write Files from Disk 节点「读取本地本地」或者「保存文件到本地」，有可能出现这个报错。

这是 Docker + n8n 文件系统权限/路径隔离 的经典问题，不是 n8n 节点用错，而是容器只能访问被允许的目录。

⚠️⚠️⚠️

想解决这个问题，首先要将你 n8n 上已有的工作流等数据找个地方保存好。因为要改环境变量，有可能会丢失数据。

⚠️⚠️⚠️

在电脑用 Docker 部署

打开 Docker，首先要在 Containers 里删掉部署好的 n8n。

然后到 Images，假设你没删掉 n8n 镜像的话，重新点击一下运行按钮。

删掉镜像了就重新拉一遍吧。可以参考《『n8n』环境搭建》

点击运行按钮后，需要添加在 Volumes 里添加一项（下图红框）。

在你的电脑，找个位置创建要给文件夹。

• 上图红框的 Host path 这项就填入你在电脑创建的文件夹的绝对路径。
• Container path 这项填入 /home/node/.n8n-files，必须是这个值！一个字一个符号都不能少！

然后点击“Run”按钮（弹窗右下角蓝色底色那个按钮）。

之后再浏览器输入 localhost:5678 就能运行 n8n 了。

接下来使用 Read/Write Files from Disk 节点读写文件，都是指向你刚刚在电脑创建的那个文件夹。

比如我的 /home/node/.n8n-files 指向了 文稿/n8n-data 这个文件夹，里面有一个 hello.txt 文件。

在 n8n 里使用 Read/Write Files from Disk 节点时，File(s) Selector 项需要这么写：

/home/node/.n8n-files/hello.txt

可以看到文件读取成功了。

记住记住！用法是这样的，别问为什么⬇️⬇️⬇️

/home/node/.n8n-files/文件名.后缀

在绿联 NAS 部署

如果你是在 NAS 上部署 n8n，通常使用 Docker 部署的吧～

不管你是用群晖还是其他牌子的NAS，如果使用新建项目，用是 yaml 拉镜像。

services:
  n8n:
    image: n8nio/n8n:latest   # 为了汉化成功，这里需要指定镜像版本号
    container_name: n8n
    ports:
      - 5678:5678
    volumes:
      - n8n:/home/node/.n8n # 冒号前面映射n8n文件夹绝对路径
      - n8n-files:/home/node/.n8n-files # 冒号前面映射n8n-files文件夹绝对路径
    restart: unless-stopped

那么 yaml 的代码必须在 volumes 里加一项 - n8n-files:/home/node/.n8n-files。冒号前面的 n8n-files 是允许 n8n 读写文件的文件夹的绝对路径。

如果你是使用《『NAS』不止娱乐，NAS也是生产力，在绿联部署AI工作流工具-n8n》里提到的方法，在 Docker 的「镜像」模块里搜索 n8n 下载部署的话，需要这么做。

我用绿联 NAS 举例，其他品牌的 NAS 操作方法大同小异。

在 Docker 的「容器」里找到 n8n，停止运行。

然后编辑它。

在 NAS 的「文件管理」里创建一个文件夹，用来给 n8n 读写文件使用的。

然后在「编辑容器」的「存储空间」里添加一项 /home/node/.n8n-files 指向那个文件夹，提供“读写”权限，如下图红框所示。

点击“保存”按钮，然后运行项目。

我在 NAS 的 n8n-files 文件夹里准备了一个 雷猴世界.txt 文件。

在 n8n 里，使用 /home/node/.n8n-files/雷猴世界.txt 这个路径就能读取到上面这个文件了。

同样，也是这个格式：

/home/node/.n8n-files/文件名.后缀

以上就是本文的全部内容啦，想了解更多n8n玩法欢迎关注《n8n修炼手册》👏

如果你有 NAS，我非常建议你在 NAS 上部署一套 n8n，搞搞副业也好，帮你完成工作任务也好 《『NAS』不止娱乐，NAS也是生产力，在绿联部署AI工作流工具-n8n》

点赞 + 关注 + 收藏 = 学会了

摘要

在鸿蒙（HarmonyOS / OpenHarmony）应用和系统开发中，IO 操作几乎无处不在，比如文件读写、配置加载、日志输出、数据库访问以及 OTA 升级等。很多性能问题表面上看是应用卡顿、启动慢、耗电高，实际上根源都指向 IO 使用不当。本文结合当前鸿蒙系统的实际开发现状，从应用层和系统层两个角度，系统梳理 IO 性能优化的常见思路，并通过可运行的 Demo 代码，讲清楚这些优化在真实项目中该怎么落地。

文章整体偏向实战，语言尽量贴近日常开发交流，适合正在做鸿蒙应用、系统服务或设备升级相关开发的同学参考。

引言

随着鸿蒙生态逐渐完善，应用形态从早期的简单页面，发展到现在的多端协同、分布式能力、设备级应用，IO 压力明显变大。一方面，应用启动阶段要加载更多配置和资源；另一方面，系统服务、后台任务、设备升级都会产生大量读写操作。

在实际项目中，经常能看到下面这些情况：

• 页面一打开就卡，结果发现主线程在读文件
• 日志一多，设备开始明显发热
• OTA 升级时间很长，写盘阶段占了一大半
• 分布式数据一同步，前台体验明显下降

这些问题并不是鸿蒙系统本身性能不行，而是 IO 的使用方式不够合理。下面我们就从最常见、也最容易优化的地方开始讲。

鸿蒙 IO 性能瓶颈从哪来

在多数项目中，IO 性能问题通常集中在下面几个点：

• 频繁进行小文件读写
• 同步 IO 放在主线程执行
• 每次用文件都重新 open 和 close
• 没有任何缓存策略
• 用文件存 KV 数据
• 日志输出不受控制

只要命中其中一两条，性能基本都会出问题。

应用层 IO 优化（最常用）

IO 一定不要放在主线程

这是最基础，也是最容易踩坑的一点。ArkTS 中如果直接使用同步文件接口，UI 线程就会被直接卡住。

错误示例

import fs from '@ohos.file.fs';

let text = fs.readTextSync('/data/storage/test.txt');

这种写法在数据量稍微大一点时，页面就会出现明显卡顿。

推荐写法（异步 IO Demo）

import fs from '@ohos.file.fs';

export async function readFileAsync(path: string): Promise<string> {
  let file = await fs.open(path, fs.OpenMode.READ_ONLY);
  let buffer = new ArrayBuffer(4096);
  let result = '';

  let readLen = await fs.read(file.fd, buffer);
  if (readLen > 0) {
    result = String.fromCharCode(...new Uint8Array(buffer, 0, readLen));
  }

  await fs.close(file);
  return result;
}

代码说明

• 使用 async/await，把 IO 操作放到异步任务中
• 读取完成后再返回结果，不阻塞 UI
• 真实项目中可以配合 taskpool 使用

合并小 IO，减少系统调用

很多性能问题不是数据量大，而是 IO 次数太多。

不推荐的写法

for (let i = 0; i < list.length; i++) {
  fs.writeSync(fd, list[i]);
}

推荐写法

let content = list.join('');
fs.writeSync(fd, content);

实际效果

• 系统调用次数明显减少
• 写盘效率更高
• 对 Flash 存储更友好

引入内存缓存，避免重复读文件

配置文件、初始化数据非常适合放进内存缓存。

let configCache: string | null = null;

export async function getConfig(path: string): Promise<string> {
  if (configCache !== null) {
    return configCache;
  }
  configCache = await readFileAsync(path);
  return configCache;
}

使用场景

• 应用启动配置
• JSON 静态数据
• 权限或状态信息

能用 Preferences 就别用文件

对于少量 KV 数据，文件 IO 的性价比非常低。

Preferences Demo

import preferences from '@ohos.data.preferences';

export async function saveUserInfo(context, userId: string) {
  let pref = await preferences.getPreferences(context, 'user_config');
  await pref.put('userId', userId);
  await pref.flush();
}

优点

• 内部自带缓存
• 自动批量落盘
• 使用简单，性能稳定

系统层 IO 优化（Native / 服务侧）

使用缓冲 IO

在系统服务或 Native 模块中，直接写裸 IO 往往效率不高。

#include <stdio.h>

void writeFile(const char* path, const char* data, size_t len) {
    FILE* fp = fopen(path, "w");
    if (!fp) return;

    setvbuf(fp, nullptr, _IOFBF, 8 * 1024);
    fwrite(data, 1, len, fp);
    fclose(fp);
}

说明

• 设置 8KB 缓冲区
• 减少实际写盘次数
• 适合大量顺序写场景

顺序 IO 优于随机 IO

off_t offset = 0;
pread(fd, buffer, size, offset);
offset += size;

尽量避免频繁 seek 和交叉读写多个文件。

控制日志 IO

日志在调试阶段很有用，但在正式环境中是 IO 隐形杀手。

if (__DEV__) {
  console.info('debug log');
}

建议：

• 发布版本关闭 debug 和 info
• 避免循环内打印日志
• 合并日志输出

典型应用场景分析

场景一：应用启动阶段加载配置

问题

启动慢，页面白屏时间长。

解决方案

• 异步读取配置
• 内存缓存

await getConfig('/data/storage/app_config.json');

场景二：OTA 升级文件写入

问题

升级包大，写盘耗时长。

优化思路

• 分块下载
• 分块写入
• 写完再统一校验

async function writeChunk(fd: number, data: Uint8Array) {
  await fs.write(fd, data.buffer);
}

场景三：日志过多导致设备发热

问题

设备运行一段时间后发热、掉帧。

解决方案

• 控制日志级别
• 关闭非必要日志

常见问题 QA

Q：异步 IO 一定比同步快吗？
A：不一定，但一定不会卡 UI。

Q：缓存会不会导致数据不一致？
A：需要设计好更新策略，配置类数据问题不大。

Q：文件和 RDB 怎么选？
A：结构化数据选 RDB，大文件选文件。

总结

IO 性能优化并不复杂，关键在于使用方式是否合理。大多数性能问题，并不是因为设备性能不足，而是 IO 用得太随意。

简单总结几句话：

• IO 不要放主线程
• 少做小 IO，多做批量 IO
• 能缓存就缓存
• 能不用文件就不用文件
• 日志一定要克制

这些原则在应用层、系统层、OTA 场景中都是通用的。如果你正在做鸿蒙系统相关开发，把 IO 优化当成基本功，会少踩很多坑。