Directory.CreateDirectory未生成目录因非法字符、权限不足或父目录不存在；Directory.Delete需传true才删非空目录；GetFiles内存高，EnumerateFiles更省资源；时间戳差异源于时区与精度。
Directory.CreateDirectory 创建目录时为什么没报错却没生成？
因为路径里有非法字符、权限不足，或者父目录根本不存在——Directory.CreateDirectory 不会自动创建上级路径，除非你给的是绝对路径且父级已存在。
- 务必检查
path字符串是否含*、?等 Windows 非法字符（用Path.GetInvalidPathChars()可验证） - 如果目标是
"logs\2024\04\daily"，而"logs"目录不存在，调用会静默失败（实际返回 null 或抛异常取决于 .NET 版本），应先确保父级存在或改用Path.GetDirectoryName()逐级创建 - 在 Docker 容器、受限服务账户下运行时，即使路径合法也可能因无写权限导致创建失败，建议加
try/catch (UnauthorizedAccessException)
Directory.Delete 删除非空目录为什么会报错？
Directory.Delete(path) 默认只删空目录；想删整个目录树，必须显式传 true 第二个参数——但这也意味着它会跳过只读文件、隐藏文件等“受保护”内容，直接抛 IOException。
- 正确写法是：
Directory.Delete(path, true)，但前提是所有子项都可被当前进程访问和删除 - 若目录含只读文件（比如日志被其他进程锁定），得先遍历重置属性：
File.SetAttributes(file, FileAttributes.Normal) - .NET 6+ 推荐改用
Directory.EnumerateFileSystemEntries()+ 手动递归删除，可控性更强，也方便跳过特定文件
Directory.GetFiles 和 EnumerateFiles 性能差在哪？
Directory.GetFiles() 一次性加载全部路径到内存数组，适合小目录；Directory.EnumerateFiles() 返回 IEnumerable<string></string>，边遍历边 yield，内存占用低，但首次迭代前不触发 IO。
- 处理上万文件的目录时，用
GetFiles()可能瞬间吃掉几百 MB 内存，而EnumerateFiles()基本恒定几十 KB - 两者默认都不进子目录，要递归得加
SearchOption.AllDirectories，但后者在深层嵌套中容易触发“路径太长”错误（Windows MAX_PATH 限制） - 搜索模式如
"*.log"在两者中行为一致，但正则匹配需自己封装，它们本身不支持
Directory.GetCreationTime 等时间戳为什么和资源管理器显示不一致？
不是 bug，是时区和精度差异：Windows 资源管理器默认显示本地时区下的“最后修改时间”，而 Directory.GetCreationTime() 返回的是 UTC 时间（.NET Core 3.0+ 默认），且精度为 100ns，资源管理器四舍五入到秒。
- 显示前务必转本地时区：
dirInfo.CreationTime.ToLocalTime()，否则看起来像“时间错乱” - NTFS 文件系统本身对创建时间（
CreationTime）并不总可靠——移动/复制文件时，不同操作会重置不同时间戳，LastWriteTime最稳定 - 跨网络共享路径（如 SMB）读取时间戳可能受服务器时钟偏移影响，别拿它做精确同步判断
Directory 静态方法堆逻辑；遇到深层遍历、权限混合、符号链接或长路径，早一点切到 DirectoryInfo 实例，它的 GetDirectories()、Attributes、Exists 更直观，也更容易 mock 测试。 
