我使用 S3 进行附件存储，因此可以处理高达 160GB 的数据。
我将 nginx 的限制更改为 0（无限制）。
app.yml 参数 “upload_size” 也设置为 0。
我们不会直接将文件上传到 S3，而是先发送到您的服务器，再由服务器转发至 S3。这意味着您设置的限制不应超过您的可用磁盘空间。
3 个赞
好的，我想将限制设置为 10GB，我的磁盘空间充足。但我该如何更改 Discourse 的限制？
1 个赞
您可以使用自定义插件覆盖最大值。您可以将此插件作为示例：
6 个赞
谢谢，我可以确认，使用此插件和以下设置后，限制已取消：
files:
max_attachment_size_kb:
client: true
default: 1024000
max: 6144000
不过，我遇到了两个问题：
- 上传 2GB 文件时，上传过程可以顺利进行到 100%，但随后会因通用弹窗错误而失败。
- 每次尝试上传时，Discourse Docker 的体积都会增加 2GB，且无法自动清理！我的磁盘空间快用完了……该如何清理这些空间？
1 个赞
您最好使用自己选择的合适云存储服务，并在 Discourse 主题中链接相关文件。Discourse 并非设计用于作为大型文件存储工具。
5 个赞
我正在使用 S3 云存储。Discourse 本身不应存储任何内容。
我不是那个意思——我指的是像 Google Drive、OneDrive、Dropbox 等面向消费者的云盘服务。
无论采用何种方式，Discourse 并非为处理大文件而设计。
3 个赞
无论文件最终存放何处，Discourse 本身也不打算作为一个臃肿的文件上传机制。
1 个赞
我理解这并非有意为之，但若能实现，对我而言将是一项极好的功能，也能提升用户体验，因为用户无需跳转到其他服务进行上传再返回 Discourse。因此，希望您不要介意我尝试使其运行，尽管这并非最初开发时的意图。
开源的魅力在于你可以自由地进行尝试。
同样，如果某项功能不受支持，也无法保证未来对 Discourse 的修改不会导致你今天所做的调整在未来完全无法使用。
1 个赞
我考虑在我的网站上允许上传大文件（可能达到 50MB，并且有可能通过 API 进行批量上传）。我只是想了解一下这里的顾虑。如果 S3 已配置为处理大文件的上传和存储，而 Discourse 论坛仅链接到这些文件以向用户显示下载链接，那么有人能详细说明一下你们预计 Discourse 会在哪里出现问题吗？
当前的上传组件并非专为大文件上传设计（仅管理后台中的备份上传功能支持）。
我们目前正在对上传代码进行标准化和重构，计划支持直接上传至 S3。一旦完成，技术上即可实现向 S3 的大文件上传。
5 个赞
谢谢你的信息，@sam。我之前并不了解文件上传是如何存储的。看来，默认情况下，文件上传是存储在运行 Discourse 的同一台服务器上的——在这种情况下，我理解为什么大文件上传可能会成为问题。我也明白你们正在努力在未来支持直接上传到 S3。
如果现在按照这里的描述，将文件上传配置为发送到 S3，会怎样呢？
这样做是否能提供与你们计划未来作为自动功能发布的相同优势，并让 Discourse 支持大文件的上传（和下载）？
我们当前的上传系统是 用户 → Discourse 服务器 → S3。
我们几周后将推出的新系统则是 用户 → S3。
5 个赞
站点能否顺利过渡到新的上传系统，即旧系统的上传功能仍然可用，同时新系统的上传功能也能正常工作？
我推测是可以的，因为所有内容都将存储在 S3 上，但仍想确认一下。谢谢。
由于文件最终会存放在同一位置，只是绕路更少，因此这一变化对用户和管理员而言都是透明的。
澄清一下：我预计用户根本不会察觉到任何变化——最多只是（也许？）他们的文件上传和下载速度会变快，并且如果管理员愿意，这将支持更大的文件上传。是这样吗？
1 个赞
它们的上传速度应该会更快。下载速度应保持不变（因为该功能仅影响上传）。
我认为是这样，但具体还需等待 Discourse 团队发布官方声明。
1 个赞