Files.size() 默认返回符号链接指向的目标文件大小，而非链接自身；需区分统计目标还是链接、防范硬链接重复计数，批量场景优先用 Files.walkFileTree 中的 attrs.size() 提升性能。
Files.size() 方法本身不“处理”符号链接，它默认返回符号链接指向的目标文件大小——这是它的设计行为，不是缺陷，但容易被误用。要高效且安全地获取文件大小，关键不在绕过符号链接，而在于明确你统计的到底是“链接本身”还是“链接所指”。
理解 Files.size() 对符号链接的真实行为
当传入一个符号链接路径时，Files.size() 会自动解析并返回目标文件的实际字节大小（前提是可访问）。它不会返回链接文件自身的元数据大小（通常只有几十字节）。这点和 file.length() 一致，但 Files.size() 更可靠：它基于 NIO 的 BasicFileAttributes，能更好适配不同文件系统，且在 walkFileTree 中已预加载 attrs，比反复调用 Files.size() 更快。
- 若路径是普通文件 → 返回该文件大小
- 若路径是符号链接 → 默认解析后返回目标文件大小（非链接自身）
- 若路径不可达或权限不足 → 抛 IOException，需显式捕获
避免“重复计数”陷阱：硬链接与符号链接的区别
符号链接只是路径别名，不影响磁盘占用；而硬链接指向同一 inode，多个硬链接代表同一份物理数据。Files.size() 对硬链接也返回相同值——这本身没错，但如果你在遍历中累加所有路径（比如用 Files.list() + 递归），硬链接会被多次计入，导致总大小虚高。真正需要防范的是硬链接重复，而非符号链接。
- Files.walkFileTree() 默认不跟随符号链接，所以软链本身不会被展开统计
- 若启用 FOLLOW_LINKS，则软链目标会被计入，但要注意：若目标是目录且含循环软链，可能陷入无限遍历
- 硬链接无法通过 Path 或 File 直接识别，需用 Files.getAttribute(path, "unix:ino")（仅 Linux/macOS）比对 inode
高效使用的三步实践建议
不用过度封装，直接用好 Files.size() 的上下文优势：
立即学习“Java免费学习笔记（深入）”；
- 单文件场景：先检查 Files.exists(path) && !Files.isDirectory(path)，再 try-catch 调用 Files.size(path) —— 不要省略异常处理，尤其访问 /proc、/sys 等虚拟路径时易失败
- 批量遍历场景：配合 Files.walkFileTree()，在 visitFile(Path file, BasicFileAttributes attrs) 中直接用 attrs.size()，它比 Files.size(file) 更快（避免重复系统调用），且已包含符号链接解析结果
- 需排除符号链接自身：用 Files.isSymbolicLink(path) 判断，若为 true 且你只想统计“链接文件”（极少见），则改用 Files.readSymbolicLink(path) 获取目标路径再 size，或直接跳过
替代方案：什么时候不该用 Files.size()
如果目标是精确统计磁盘实际占用（如稀疏文件、压缩卷、ReFS 上的重删数据），Files.size() 返回的是逻辑大小（logical size），不是物理占用（disk usage）。此时应调用平台命令（如 du -sb）或使用 JNI 调用 stat.st_blocks × 512，但代价是失去跨平台性。
- 绝大多数业务场景（上传校验、空间预估、日志归档）用 Files.size() 完全足够
- 监控级精度要求（如备份系统报告真实磁盘消耗）才需绕过 NIO，直查底层块信息
- 不要为“规避符号链接”而禁用 FOLLOW_LINKS 后又手动 resolve —— 这反而增加开销且逻辑更脆弱
