laravel 文件上传中的存储和移动方法之间是否存在差异以及何时使用其中一种方法？
Is there a difference between store and move methods in laravel file upload and when to use one over the other?
上传图片时，我首先意识到我可以使用 store method，它默认将图片保存在 storage/app/public 中，然后我必须从 public/storage 创建一个 symbolic link storage/app/public 访问图像。
其次，我仍然可以使用 move method 并将图像直接保存在 public/images 中。
我觉得第一种方式无缘无故地更长，是否存在何时使用一种而不是另一种的情况，或者这只是一个偏好问题？
来自 laravel 文档 https://laravel.com/docs/5.4/filesystem:
move method may be used to rename or move an existing file to a new location
Laravel makes it very easy to store uploaded files using the store method on an uploaded file instance.
因此，当您处理已上传的文件时（即在控制器中），请使用 storeAs() 或 store()，并且仅当您已经拥有时才使用 move()磁盘中的一个文件，将其从一个位置移动到另一个位置。
是的，在某些情况下会更好，但它可能与您无关，让我解释一下。
storage 文件夹通常被认为是“共享”文件夹。我想说的是，当你部署你的应用程序时，内容通常不应该改变，而且大部分内容通常甚至在 git 中被忽略（以防止你的上传最终在你的 git 存储库）。
因此，在这种情况下，将您的上传存储在 storage/app/public 目录中意味着内容不在 git 中，并且 storage 文件夹可以在部署之间共享。
这在您使用 Envoyer, Envoy 或其他“零停机”部署工具时很有用。
大多数（如果不是全部）零停机部署工具通过将应用程序克隆到新目录和 运行 composer install 以及其他设置命令来工作，然后再将该新目录提升到 current 您的网络服务器用来为您的应用程序提供服务的目录。将符号链接更改为新目录是即时的，因此您的停机时间为零，因为所有设置（安装依赖项等）都是在尚未向用户提供流量的文件夹中完成的。
并且由于每次部署都从您的存储库的新克隆开始，这也意味着您的 public 和 storage 文件夹再次为空...这不是您想要的，因为您当然想要保留部署之间的上传。一种解决方法是这些部署工具会将 storage 文件夹存储在另一个文件夹中，并且每次部署都会克隆您的 git 存储库并将 storage 文件夹符号链接到共享 storage 文件夹，以便您的所有部署共享相同的 storage 目录，确保上传（但取决于您使用的驱动程序以及会话、缓存和日志）对于每个部署都是相同的。
然后您可以使用 php artisan link 将 storage/app/public 符号链接到 public/storage，以便公开访问这些文件。
（注意：有了符号链接，写入哪个路径并不重要，storage/app/public 或 public/storage 因为它们指向磁盘上的同一个文件夹）。
所以这个看似过于复杂的符号链接舞蹈是为了让部署更容易，并将所有“存储”放在一个地方，即 storage 目录。
但是当您不使用那些零停机时间部署工具时，这一切似乎都是胡说八道。但即便如此，将所有应用程序存储保存在一个位置以进行备份仍然可能很有用，而不是必须备份多个目录。
上传图片时，我首先意识到我可以使用 store method，它默认将图片保存在 storage/app/public 中，然后我必须从 public/storage 创建一个 symbolic link storage/app/public 访问图像。
其次，我仍然可以使用 move method 并将图像直接保存在 public/images 中。
我觉得第一种方式无缘无故地更长，是否存在何时使用一种而不是另一种的情况，或者这只是一个偏好问题？
来自 laravel 文档 https://laravel.com/docs/5.4/filesystem:
movemethod may be used to rename or move an existing file to a new location
Laravel makes it very easy to store uploaded files using the
storemethod on an uploaded file instance.
因此，当您处理已上传的文件时（即在控制器中），请使用 storeAs() 或 store()，并且仅当您已经拥有时才使用 move()磁盘中的一个文件，将其从一个位置移动到另一个位置。
是的，在某些情况下会更好，但它可能与您无关，让我解释一下。
storage 文件夹通常被认为是“共享”文件夹。我想说的是，当你部署你的应用程序时，内容通常不应该改变，而且大部分内容通常甚至在 git 中被忽略（以防止你的上传最终在你的 git 存储库）。
因此，在这种情况下，将您的上传存储在 storage/app/public 目录中意味着内容不在 git 中，并且 storage 文件夹可以在部署之间共享。
这在您使用 Envoyer, Envoy 或其他“零停机”部署工具时很有用。
大多数（如果不是全部）零停机部署工具通过将应用程序克隆到新目录和 运行 composer install 以及其他设置命令来工作，然后再将该新目录提升到 current 您的网络服务器用来为您的应用程序提供服务的目录。将符号链接更改为新目录是即时的，因此您的停机时间为零，因为所有设置（安装依赖项等）都是在尚未向用户提供流量的文件夹中完成的。
并且由于每次部署都从您的存储库的新克隆开始，这也意味着您的 public 和 storage 文件夹再次为空...这不是您想要的，因为您当然想要保留部署之间的上传。一种解决方法是这些部署工具会将 storage 文件夹存储在另一个文件夹中，并且每次部署都会克隆您的 git 存储库并将 storage 文件夹符号链接到共享 storage 文件夹，以便您的所有部署共享相同的 storage 目录，确保上传（但取决于您使用的驱动程序以及会话、缓存和日志）对于每个部署都是相同的。
然后您可以使用 php artisan link 将 storage/app/public 符号链接到 public/storage，以便公开访问这些文件。
（注意：有了符号链接，写入哪个路径并不重要，storage/app/public 或 public/storage 因为它们指向磁盘上的同一个文件夹）。
所以这个看似过于复杂的符号链接舞蹈是为了让部署更容易，并将所有“存储”放在一个地方，即 storage 目录。
但是当您不使用那些零停机时间部署工具时，这一切似乎都是胡说八道。但即便如此，将所有应用程序存储保存在一个位置以进行备份仍然可能很有用，而不是必须备份多个目录。