ec2挂载efs必须用linux实例，windows不支持；安全组需双向放行2049端口；挂载命令须指定nfsvers=4.1；lambda需vpc内且配置access point；c#读写要注意权限、编码、原子性及并发陷阱。
EC2 上挂载 EFS：必须用 Linux 实例，Windows 不支持
Amazon EFS 本质是 NFSv4.1 文件系统，AWS 官方只支持在 Linux EC2 实例上挂载。如果你用的是 Windows Server 实例，mount 命令会直接报错，或者挂载后显示为空目录——这不是权限问题，是协议层不兼容。
实操建议：
- 启动 EC2 时选
Amazon Linux 2或Ubuntu 22.04+，避免用老旧 AMI（如 AL1）导致内核缺少 NFSv4.1 支持 - 安全组必须双向放行
2049端口（NFS server port），且源/目标需设为 EFS 的安全组 ID，不能只写0.0.0.0/0 - 挂载命令用
sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noac <code>fs-xxxxxx.efs.us-east-1.amazonaws.com:/ /mnt/efs；漏掉nfsvers=4.1在某些内核下会 fallback 到 v3，导致挂载成功但写入失败 - 把挂载写进
/etc/fstab时，务必加_netdev选项，否则实例重启可能卡在 mount 阶段
Lambda 无法直接挂载 EFS：不是配置问题，是架构限制
AWS Lambda 是无状态容器，不提供传统文件系统挂载能力。所谓“Lambda 挂载 EFS”，其实是通过 Lambda 函数运行时自动挂载的 EFS 访问点（Access Point），但前提是函数必须部署在 VPC 内，且该 VPC 的子网要与 EFS 所在子网有路由可达。
常见错误现象：
- 函数超时（默认 15 秒），日志里出现
Failed to mount EFS file system—— 很可能是安全组没放开2049，或子网没关联正确路由表 - 挂载成功但读写报
Operation not permitted—— EFS Access Point 的RootDirectory权限设置太严，或 Lambda 执行角色没被授予elasticfilesystem:ClientMount和elasticfilesystem:ClientWrite - 并发高时大量
Input/output error—— EFS 的General Purpose模式吞吐随 I/O 量动态伸缩，但突发写入超过 50 MiB/s 可能触发限速；改用Max I/O模式并预置吞吐更稳
C# 代码读写 EFS：当成本地路径，但要注意权限和编码
挂载成功后，EFS 对 C# 来说就是个普通 Linux 路径，System.IO.File.ReadAllText("/mnt/efs/config.json") 能直接用。但实际踩坑最多的是权限和字符集。
关键点：
- EFS 上文件默认属主是
root，而 Lambda 运行时用户是sbx_user1051（UID 1051），EC2 上默认是ec2-user（UID 1000）。必须用chown或 EFS Access Point 的uid/gid映射来对齐 - 别用
File.WriteAllText直接覆盖大文件，EFS 的 NFS 层不保证原子写；应先写临时文件（如/mnt/efs/data.tmp），再用File.Move替换原文件 - Linux 默认用 UTF-8，但 .NET 的
Encoding.Default在某些 AMI 上可能是 ISO-8859-1，读中文会乱码；显式指定Encoding.UTF8 - 频繁小文件读写性能差——EFS 单次 I/O 延迟比本地 SSD 高 5–10 倍，批量操作优先用
Directory.GetFiles+Parallel.ForEach，而非逐个File.Exists
EC2 和 Lambda 共享 EFS 时的并发陷阱
多个 Lambda 实例或 EC2 进程同时写同一个文件，不会自动加锁。C# 的 FileStream 构造函数传 FileShare.None 在 EFS 上无效——NFS 协议本身不支持强制字节级锁。
安全做法：
- 用 EFS Access Point 配合
CreationInfo设置默认 umask 和 uid/gid，确保所有写入者权限一致 - 避免“读-改-写”模式，改用追加日志（
File.AppendAllText）或基于时间戳的临时文件名 - 需要强一致性场景（比如计数器），不要依赖文件，改用
DynamoDB或Redis；EFS 适合共享配置、静态资源、日志归档这类最终一致性场景 - 监控
PercentIOLimit和ClientConnectionsCloudWatch 指标，长期 >80% 表示该拆分 EFS 文件系统了
真正麻烦的从来不是挂载命令对不对，而是挂上之后忘了 NFS 的缓存行为、权限模型和并发语义跟本地磁盘根本不是一回事。
