这是我的环境。请注意，这也设置在相关的开发模式和生产模式中。
Dev:
https://ar.dev.loc/
https://en.dev.loc/
Live:
https://ar.site.com/
https://en.site.com/
我使用的是阿拉伯语和英语的多商店设置，一切都很好，包括构建模块和模板构建。
然而，如果我对任何less文件或JS文件进行更改（尽管使用了grunt less或grunt watch），我必须在我的开发环境中每次运行以下命令，才能在本地机器上看到它们。
$ rm -rf var/cache var/page_cache var/view_preprocessed pub/static
$ mkdir pub/static
$ bin/magento setup:static-content:deploy
$ bin/magento setup:static-content:deploy ar_SA
$ grunt exec less // sometimes I leave this do this
$ grunt // I swap between these
每次都要花很长时间来完成这个过程。这很令人沮丧，因为我是一个快速编码的人，喜欢在网站上立即看到CSS和Less，而不是等待。
我们团队正在做的快速方法实际上是在pub/static中进行更改，然后我们将这些更改发送到less和app/design等，然后执行上面的过程，然后git。
Live服务器基本相同。Git拉，然后维护模式（在一个实时电子商务网站上疯狂！谁构建M2？？然后我们运行以上命令-停机45分钟）
当然，我们的部署、开发和团队必须有一种更快的方式来更好地工作，并在没有停机的情况下更快地看到变化！
甚至Magento 2官方文档也表示，您的LIVE网站需要进入维护和停机模式才能发布内容-这不是我们的选择。CTO对此并不满意。简直荒谬
与人们询问更快开发的相关问题相同的问题：
CS的更改仅反映在magento2 中部署命令之后
Magento 2静态缓存
对CSS和JavaScript的更改仅在部署静态内容后适用
所以我想整理所有的问题并解决这个问题。
是的，通过以下步骤可以更快：
- 在应用程序目录中更改js/css文件
- 现在删除pub/static文件夹中的文件
您可以通过以下命令在pub-static中找到该文件
find pub/static -iname yourjsfile.js
- 仅从pub/static文件夹中删除其中有更改的文件
- 确保pub/static.htaccessfile&pub/static.php文件存在
- 为pub文件夹分配文件写入权限
- 现在点击浏览器中的URL。htaccess将直接部署丢失的js文件
pub/static中的.htaccess使用参数resource将丢失的文件发送到pub/static.phppub/static.php文件为该文件创建一个StaticResource（如果可用）并部署它。
注意：这只适用于apachemod_rewrite
对于Nginx，您需要通过Nginx.conf.sample
配置相同的流程。由于我使用-j (--jobs)选项来派生新流程，我将static-content:deploy时间从10分钟以上减少到1分钟以下。参见Magento/Deploy/Process/Queue.php
php bin/magento setup:static-content:deploy -j[JOBS_AMOUNT]
--jobs选项可使用指定数量的作业启用并行处理。默认值为4。要使任务在一个进程中运行（例如，如果系统不支持进程分叉），请使用--jobs 1。//请参阅：devdocs.magento.com
仅当启用了pcntl时，才能使用此选项。
pcntl
不需要任何外部库来构建此扩展。
默认情况下，PHP中的进程控制支持是而不是。
编译PHP时，必须使用--enable-pcntl配置选项编译CGI或CLI版本的PHP，以启用Process Control支持。
注意：目前，此模块将在非Unix平台（Windows）上不起作用。
注意：如果PHP作为Apache模块运行，
pcntl_fork将不工作，在这种情况下，此函数将不存在！
我已经有一段时间没有接触setup:static-content:deploy了。在厌倦了Magento 2中缓慢的部署过程后，我设计了自己的程序，允许我对CSS或JS文件进行更改，并几乎立即在网站上反映出来。神奇之处在于：
cd /path/to/docroot/app/design/frontend/$VENDOR/$THEME
find * -type f ( -name "*.css" -o -name "*.js" ) -cmin -10 | xargs -I {} bash -c 'dest=/path/to/docroot/pub/static/frontend/$VENDOR/$THEME/*/$(echo {} | sed -E "s/(web/|/[^/]+$)//g"); echo Deploying {} to $dest ...; mkdir -p $dest && cp {} $_'
cd - 1> /dev/null
让我们把它分解。。。
cd /path/to/docroot/app/design/frontend/$VENDOR/$THEME-更改为活动主题目录（用您自己的值替换$VENDOR和$THEME）find * -type f ( -name "*.css" -o -name "*.js" ) -cmin -10-在主题目录中查找最近10分钟内以任何方式更改的所有CSS和JS文件（*去掉了结果中领先的./）；随时更改任何参数以满足您的需求xargs -I {} bash -c-对于每个更改的文件，执行#4-6中的命令（更改文件的相对路径存储在{}中）dest=/path/to/docroot/pub/static/frontend/$VENDOR/$THEME/*/$(echo {} | sed -E "s/(web/|/[^/]+$)//g")-设置部署目标路径*glob负责匹配您所在的任何语言环境$(...)生成一个子shell，只提取源路径中需要附加到目标路径的部分（pub下不存在web目录级别）
echo Deploying {} to $dest ...-将活动记录到控制台，以便了解正在部署的文件mkdir -p $dest && cp {} $_-创建目的地目录结构；如果并且仅当成功创建目录结构时，将更改后的文件复制到pub下的部署目标（$_指向上一个命令的最后一个参数mkdir，即$dest）cd - 1> /dev/null-更改到上一个目录，以便您可以继续您停止的位置
您可以将所有这些放入别名中，将其简化为一个命令，但请记住转义单引号：
alias update='cd /path/to/docroot/app/design/frontend/$VENDOR/$THEME; find * -type f ( -name "*.css" -o -name "*.js" ) -cmin -10 | xargs -I {} bash -c '"'"'dest=/path/to/docroot/pub/static/frontend/$VENDOR/$THEME/*/$(echo {} | sed -E "s/(web/|/[^/]+$)//g"); echo Deploying {} to $dest ...; mkdir -p $dest && cp {} $_'"'"'; cd - 1> /dev/null'
如果您使用varnish，那么您应该在别名（例如，sudo service varnish restart）的末尾添加一个重新启动varnish的命令，否则您可能仍然会遇到缓存的静态资产。
如果每次进行更改时都懒得键入update，那么可以将其放入cron中，或者将其集成到grunt监视器任务或等效任务中。
一般评论：
在这里，您不能像设置：静态内容：部署那样"咕哝"。您可以并行生成en_US（即不包含参数）和ar_SA的静态内容（bash使您可以很容易地做到这一点）。
如果您错过了HTTPS（安全）资源（也许这就是您额外使用grunt的原因？），请确保为编译静态内容（ref）的进程设置了环境变量"HTTPS"（例如HTTPS=ON）。
除此之外，是的，这需要时间。值得注意的是，无PHP编译需要相当长的时间。当我从另一位开发人员那里听说这一点时，我想到了一个想法，那就是在一个无本地缓存中缓存较少的编译，并且只有在文件真正更改时才重新编译。也许你也可以试试。
我还不负责一起破解PoC，但我认为这应该是一个很好的测试，因为编译量少是瓶颈。
我还可以强烈建议运行一个在git push上自动编译的构建服务器，以减轻负担。
在我们公司，我们使用Capistrano管理Magento2部署，还有一个针对Magento2的特定taks集，效果非常好。
使用capistrano，您可以将Web服务器根目录配置为指向指向"发布"文件夹的符号链接。当你开始部署时，所有的编译（di、静态内容、ecc）都在一个单独的文件夹中进行，这样你的在线网站就不会受到影响，并保持在线。在过程结束时，只有在没有错误的情况下，符号链接才会切换到新版本。
通过这种方式，停机时间通常为零或减少到几秒钟。
Capistrano还提供了一个基本的"回滚"功能，允许在出现问题时快速恢复到旧版本。
我不熟悉磁电机，但这可能适用于您。当我更新我的网站时，我会遵循以下步骤：
假设站点位于site目录下。
$ cp -r site site-update
# update the site in site-update directory
$ mv site site-old && mv site-update site
这样我的网站就可以在没有任何停机时间的情况下进行更新。
我还注意到，如果你有css和js登录，如果你运行安装升级，它似乎会变得很奇怪，然后它会破坏版本，直到你重建静态内容，它才会破坏css/js。
我不知道他们认为这应该如何为生产人员工作。任何事情都可以让它摆脱困境，你必须重建。
我运气不错1.打开css/js签名2.然后你可以运行静态内容部署，似乎可以保持ur的完整性3.刷新缓存（然后将新版本12312312添加到静态url）
但说真的，部署不可能坚如磐石。
BlackBenzKid非常古玩，一年后你在那里结束了，你把马根托扔了吗？
我已经为这个问题找到了解决方案。
你必须通过发布你想要的商店的内容
php bin/magento setup:static-content:deploy [lang(en_US)] -t [vendor]/[theme]
我不会改变，因为magento缓存，所以只需手动删除
rm -rf pub/static/_*/*
php bin/magento cache:flush; php bin/magento cache:clean;
刷新你的页面，现在完成，当它重新生成页面时会进行新的更改。
这些步骤对于phtml和静态内容的更改是强制性的，布局更改需要缓存刷新，而控制器上的更改则是一件麻烦的事，因为您需要使用di：编译这个确实会让您离开生产环境。