COPY 完成的那一步有生成一层中间镜像

直接 run 那个镜像，手动去执行下命令，看看到底发生了什么，感觉是你的镜像中却了什么东西

另外，部署用的镜像建议加上 --deployment 或者 --frozen

我这边几个指向 github 的 gem，并没有遇到你说的问题

而且看上去你在 Gemfile 里仍旧使用着 git://

没有留空行吧

所以说有点歧义嘛，之前的说法容易让人理解为：『fork 可以共享所有数据（包括修改也可以）』

@huacnlee 我这边表情全挂了，浏览器没报错，返回也全是 200，但图全是裂的

『共享』有共同持有的意思，会互相影响

fork 应该是完整的 copy，在 fork 的子进程里面的操作不会在 master 中反应出来，如果需要通讯还需要借助其他手段

由于 fork 调用，新的子进程会共享当前 Master 的所有数据

这句有点歧义

/web/bag 本地的绝对路径？这个文件夹存在么

《Rails 5 敏捷开发》/ 《Agile Web Development with Rails 5》

https://about.ac/books/agile-rails5/ 国内版本的介绍，论坛里也有不少介绍

或者

《Ruby on Rails 教程（原书第 4 版）》

https://railstutorial-china.org 这本更基础点，而且有电子书

或者 ForkLift 之类的 SFTP 工具了解一下

<%= form_tag(resources_path, method: :get) do %>
  <%= label_tag(:resourcetype_id, "Search for:") %>
  <%= text_field_tag(:resourcetype_id) %>
  <%= submit_tag("类型") %>
<% end %>

这样写就不需要你加 search 方法了，改改 submit 按钮的样式，应该是你最想要的方案（如果我没理解错你想要什么）

两位大大轮番指导了，感觉你还没懂的样子，然我来给你扫个盲：

核心的问题是：你没有弄明白哪些动作是在服务器上由 Rails 执行的，哪些动作是由浏览器执行的

Rails 再厉害，它也不能跑在用户的浏览器里，所以到了客户端上，还是得按 HTML + JavaScript 的套路来

比如，你的这段代码：

<%= form_tag("/resources/search", method: "get") do %>
  <%= label_tag(:search_id, "Search for:") %>
  <%= text_field_tag(:search_id) %>
  <%= submit_tag("search") %> 
  <!-- 到这里是没有问题的，如果你点 search 你会在 search 的 get 请求里收到你提交的 search_id，用 params[:search_id] 可以取到，而帮你完成取值的是 HTML form 的默认行为 -->

  <%= link_to '搜索', search_resources_path(:resourcetype_id => params[:search_id]) %>
  <!-- 这个就，呃…… 这个 a 标签的生成是在服务器渲染时完成的，params[:search_id] 取的是渲染页面时控制器里的 params[:search_id]，跟你的表单没有一分钱的关系，不会因为你改了输入框的值这里就跟着变了，而且你应该在 search 方法里用 params[:resourcetype_id] 来取值吧 -->

  <%= link_to '类型', resources_path(:resourcetype_id => 2) %>
  <!-- 这个写死，并不知道有什么毛病 -->
<% end %>

兔羊吐神波

可能你对『庞然巨物』还有点误解，之前有个项目，如果有人更新了前端基础资源，本地 rails s 之后出去喝杯咖啡回来大概就能正常访问了

不用 capistrano 就 20s, 用了就 5min？明显是设置没对导致 cap 每次都在重新编译静态资源

打开 cap 的详细日志，看看是不是重新编译所有的静态资源

你还可以在 assets:precompile 开始的时候手动中断部署，再登录到服务器上最新一个 release 目录下检查原因

哈哈 还是更喜欢 GIL 的味道哇

这个教程只是扫盲而已，高阶操作还是要靠使用者自己修行打怪

毕竟所有的姿势，都已经写在 Capistrano 的官方文档里了

PS: Capistrano 的文档真心不错，大多数场景都不需要去看源码了

通常这个是因为 assets:precompile 导致的，应该不是每次都这样吧，只有在你修改了 js 或 css 的时候才会

如果是，可能是你没有把 /public 设置成 link_dir

所以遇到错误

正确操作：看日志，找信息，查 issues

无脑操作：卸了重来，我就不信了……

为什么装 node 可以解决这个呢？

其实并不确定他是不是装了 gcc 🤪

这个问题我也没遇到过，所以怎么处理也不是很确定

https://github.com/sparklemotion/nokogiri/issues/1111 这个里面稍微有提到一些

建议尝试：

xcode-select --install
rbenv uninstall 2.3.0
rbenv install 2.3.0
gem install nokogiri -v '1.8.2'

看看能不能解决

这个报错，有点少见了，在编译阶段触发的，感觉像是 gcc 的问题呀 在你开始装环境之前 xcode-select --install 执行了么？

原谅我居然笑出了声

需要细细去读的书，kindle 还是有点不合适

官方卖萌 最为致命 HAHAH~

需要代部署服务么？

发个悬赏 论坛里、群里肯定一片人都冒出来了

报错提示截取太少了 看不到原因 应该有生成一个 gem_make.out 的文件吧

打开看下里面爆了啥

看上去应该是你的环境缺少某个编译依赖

个人建议先拥抱 再去考虑融汇贯通

顺带吐槽一下 vue 这边目前比较火的 ssr 方案 nuxt，我去，这货完全是在开历史的倒车 (/= _ =)/~┴┴

react 没有太多了解，不过我最近在用 vue

说到这个问题，其实首先应该区分一下 服务器端渲染 vs 预渲染 (SSR vs Prerendering)，这是两个不同的概念

如果只是预渲染（Prerendering），那其实还是前后端分离的，没有什么可说的

如果是 SSR，那我就会觉得是兜了一个大圈子，最后还是来解决了一个和 turbolinks 类似的问题，也大概可以算是殊途同归了

为什么是『大概算是』呢？因为这两者导致的结果是不一样的，turbolinks 解决了 SPA 的问题，但是它没有去解决前端代码怎么去架构的问题，虽然也有像 tao_rails 这样的框架，但是它也只是在尝试解决问题，它能迎合偏后端的程序员或者全栈程序员的口味，却很难让偏前端的程序员觉得『干，用这个写起来真的好爽~』

编程使我快乐不只是 ruby 的专利

因此，基于『写起来爽』这个初衷来看，你觉得选什么方案合适呢？

关于这个问题 嗯，完全不想说话并向你扔出一篇文章：

http://chloerei.com/2018/01/07/front-end-split/