起初我想问“Windows 操作系统允许的最大子文件夹是多少”
但后来我想也许我的网络托管服务提供商不在 Windows 上，而是在 Linux 或其他平台上。因此，我想问 Web 托管提供商通常使用的所有主要操作系统允许的最大子文件夹是多少。 (说 Linux、Mac 或 Windows 安全吗？)
然后，根据您的经验，网络托管网站是否对我们可以创建的子文件夹数量设置了限制？
(为什么这样？因为我希望每个用户都有自己的文件夹，以便轻松访问他们的图像。这样可以吗？还是不好的做法？还是编程新手。)
最佳答案
限制不在于嵌套子目录的深度(您可以有几十个，甚至更多)，而在于文件系统及其配额。
还有很长的文件路径很不方便(而且效率可能有点低)。以编程方式，数百甚至数千个字符的文件路径是可能的；但是人脑无法记住这么长的文件路径。
大多数文件系统(在 Linux 上)对其数量有固定限制 inodes .
一些文件系统对包含一万个条目的目录表现不佳(例如，因为搜索是线性的而不是二分法的)。而且你很难处理它们(例如，即使是 ls * 也会给出太长的输出)。因此，使用 /somepath/a/0001 ... /somepath/z/9999 而不是 /somepath/a0001 可能是明智的... /somepath/z9999
如果你有成千上万的用户，每个用户都有他的目录，你可能想要，例如按用户首字母分组，例如有 /some/path/A/userAaron/images/foobar 和 /some/path/B/userBasile/images/barfoo 等等 所以 /some/path/A/ 将只有数百个子目录等...
一个方便的经验法则可能是:避免超过几百个条目 - 子目录或文件 - 每个目录。
一些 Web 应用程序将小数据 block 存储在 SQL 数据库的单独行中，并使用文件(其名称可能会生成)用于较大的数据 block ，将文件路径存储在数据库中。拥有数百万个文件且大多数文件只有几十个字节可能效率不高。
一些系统管理员也在使用 quotas在文件系统上。
关于linux - 子文件夹的最大允许深度是多少？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15516816/