主要問題在于這語句：

<%= form_for([@comment.commentable,@comment]) do |f| %>

這句實(shí)質(zhì)就是<%= form_for([@question, @comment]) do |f| %>
url： "/questions/2/comments" （post請(qǐng)求）
也就是說你是給這個(gè)question添加評(píng)論，需要comments控制器，并定義create方法
但是你沒有定義

在爆棧問到原因了，是因?yàn)?code>JObject除了本身實(shí)現(xiàn)了一個(gè)IEnumerable<KeyValuePair<string, JToken>>，它實(shí)現(xiàn)的另一個(gè)接口JContainer也實(shí)現(xiàn)了一個(gè)IEnumerable<JToken>，等于JObject直接和間接實(shí)現(xiàn)了兩個(gè)不同的IEnumerable<T>，當(dāng).Select的時(shí)候編譯器不能確定調(diào)用哪個(gè)類型的Select，所以就這樣了。

可以將jobj顯式轉(zhuǎn)換為IEnumerable<XXX>后調(diào)用。

可以用swoole的table或者redis存你需要毫秒數(shù)n，然后用8640000的timer觸發(fā)后，n =n-8640000，如果n小于8640000，就可以新建一個(gè)n毫秒的timer，否則建一個(gè)8640000的timer，如此循環(huán)。

sudo pip3 install scrapy

set_error_handler,set_exception_handler,register_shutdown_function這三個(gè)方法，可以找各種框架看看他們的錯(cuò)誤異常接管，也可以用whoops這種現(xiàn)成的類庫。

下面的數(shù)據(jù)是antdesign的table使用columns的到的數(shù)據(jù)

對(duì)于參數(shù)綁定為何可以避免SQL注入，建議題主可以了解一下，值得注意的是prepare語句只能解析一條SQL，下面摘要說明一下prepare的作用：
首先從mysql服務(wù)器執(zhí)行sql的過程開始講起，SQL執(zhí)行過程包括以下階段 詞法分析->語法分析->語義分析->執(zhí)行計(jì)劃優(yōu)化->執(zhí)行。詞法分析->語法分析這兩個(gè)階段我們稱之為硬解析。詞法分析識(shí)別sql中每個(gè)詞，語法分析解析SQL語句是否符合sql語法，并得到一棵語法樹（Lex）。對(duì)于只是參數(shù)不同，其他均相同的sql，它們執(zhí)行時(shí)間不同但硬解析的時(shí)間是相同的。而同一SQL隨著查詢數(shù)據(jù)的變化，多次查詢執(zhí)行時(shí)間可能不同，但硬解析的時(shí)間是不變的。對(duì)于sql執(zhí)行時(shí)間較短，sql硬解析的時(shí)間占總執(zhí)行時(shí)間的比率越高。而對(duì)于淘寶應(yīng)用的絕大多數(shù)事務(wù)型SQL，查詢都會(huì)走索引，執(zhí)行時(shí)間都比較短。因此淘寶應(yīng)用db sql硬解析占的比重較大。

Prepare的出現(xiàn)就是為了優(yōu)化硬解析的問題。Prepare在服務(wù)器端的執(zhí)行過程如下

1） Prepare 接收客戶端帶”?”的sql, 硬解析得到語法樹(stmt->Lex), 緩存在線程所在的preparestatement cache中。此cache是一個(gè)HASH MAP. Key為stmt->id. 然后返回客戶端stmt->id等信息。

2） Execute 接收客戶端stmt->id和參數(shù)等信息。注意這里客戶端不需要再發(fā)sql過來。服務(wù)器根據(jù)stmt->id在preparestatement cache中查找得到硬解析后的stmt, 并設(shè)置參數(shù)，就可以繼續(xù)后面的優(yōu)化和執(zhí)行了。

Prepare在execute階段可以節(jié)省硬解析的時(shí)間。如果sql只執(zhí)行一次，且以prepare的方式執(zhí)行，那么sql執(zhí)行需兩次與服務(wù)器交互（Prepare和execute）, 而以普通（非prepare）方式，只需要一次交互。這樣使用prepare帶來額外的網(wǎng)絡(luò)開銷，可能得不償失。我們?cè)賮砜赐籹ql執(zhí)行多次的情況，比如以prepare方式執(zhí)行10次，那么只需要一次硬解析。這時(shí)候  額外的網(wǎng)絡(luò)開銷就顯得微乎其微了。因此prepare適用于頻繁執(zhí)行的SQL。

Prepare的另一個(gè)作用是防止sql注入，不過這個(gè)是在客戶端jdbc通過轉(zhuǎn)義實(shí)現(xiàn)的，跟服務(wù)器沒有關(guān)系。 

建議題主看下MySQL官方文檔（https://dev.mysql.com/doc/ref...）。什么？看不懂英文？試試百度翻譯吧：https://fanyi.baidu.com

瀑布流布局

參見 http://download.csdn.net/down...

• 要看這些接口的關(guān)系，如果這些接口都是從一個(gè)數(shù)據(jù)庫讀東西，一般不會(huì)只失敗一個(gè)，比較適合提供一個(gè)總的接口。
• 如果這些接口的后臺(tái)比較分散，相互比較獨(dú)立，可能會(huì)出現(xiàn)失敗一個(gè)的情況。
• 還有一個(gè)方案就是允許其中一些信息獲取不到，用一個(gè)默認(rèn)值或者報(bào)錯(cuò)信息替代，后臺(tái)設(shè)置一個(gè)超時(shí)時(shí)間，超時(shí)后就統(tǒng)一返回默認(rèn)值或者錯(cuò)誤信息

電腦端瀏覽器可以拖動(dòng)大小，手機(jī) pad上也有可能分屏，所以不能直接用屏幕大小

crontab 的環(huán)境變量和我們的賬號(hào)都不一樣, 和 root 的環(huán)境變量也不一樣.
類似普通用戶會(huì)先加載 ~/.bashrc 或者 /etc/profile, crontab 則會(huì)在運(yùn)行時(shí)加載 /etc/crontab 導(dǎo)入其環(huán)境變量.
因此不妨看看 scrapy 這條命令是否被加入了 crontab 的運(yùn)行環(huán)境變量里: /etc/crontab .

其實(shí)最簡單的辦法, 是在 crontab 里執(zhí)行定時(shí)任務(wù)時(shí), 盡量用絕對(duì)路徑:

2 2 *** cd /root/EIT/crawler/EIT && /path/to/scrapy crawl test

如果不知道 scrapy 這條命令被放在哪里了, 可以執(zhí)行如下兩條命令來找到這個(gè)路徑:

whereis scrapy
which scrapy

你的網(wǎng)站的權(quán)重怎么可能和博客園去比啊，
segmentfalut 還做到了一個(gè)問題發(fā)布，幾分鐘內(nèi)就可以被百度搜索到呢，
segmentfalut 運(yùn)維，出來談?wù)?，你們是怎么做到?/p>

可以實(shí)時(shí)的把blob通過ajax提交給后端

1.你cookie是在哪里設(shè)置的，設(shè)置cookie的域名和api接口的域名是不是同一個(gè)，不是同一個(gè)是帶不上的

如果我沒有猜錯(cuò), 你用的是 VirtualBox 虛擬機(jī)引擎.

enp0s3(10.0.2.15) 這是 VirtualBox 的默認(rèn)網(wǎng)卡, 可透過宿主機(jī)(這里指你的 windows) 連接外網(wǎng). 沒有它虛擬機(jī)就上不了外網(wǎng)了. 它使用 NAT 模式, 你可以打開一個(gè) VirtualBox 虛擬機(jī)的網(wǎng)絡(luò)設(shè)置了解一下其他模式.

而 enp0s8(192.168.33.34) 是你配置的另一張網(wǎng)卡, 只能透過宿主機(jī)訪問.

dubbo沒有使用經(jīng)驗(yàn), 但做為RPC框架, 實(shí)際服務(wù)執(zhí)行是在遠(yuǎn)端的, 是不必下載jar到本地的. 知道接口就可以了.A依賴B, 也不需要B的全部代碼都加到A里, 只要接口就好.

發(fā)現(xiàn)最後是編輯器問題～

移動(dòng)端需要考慮moz？

好吧如果確實(shí)需要考慮，就集體overflow:hidden然后用js模擬滾動(dòng)好了。

這是thymeleaf 2的bug ，升級(jí)到thymeleaf 3可以解決此bug；

thymeleaf2的時(shí)候是自己處理的json；
thymeleaf3使用的jackson，jackson可以通過使用@JsonIgnoreProperties和@JsonIgnore注解解決 兩個(gè)類互相引用的問題