你拿到的是源代碼，你看到的是經(jīng)過js渲染后的代碼。

建議大家放棄npm，擁抱yarn，換用yarn后問題解決。

沒懂 覆蓋了就用覆蓋之后的吧

使用fliter+switchIsEmpty+flitermap就可以了

CDN 一般都是用在靜態(tài)資源上，通常都會(huì)使用子域名。

比如 Server 端域名是：www.xxx.com, 那么 CDN 通常會(huì)用 cdn.xxx.com 這樣的子域名來接入到第三方 CDN 服務(wù)商（阿里云，七牛云，又拍云等），你直接用 Server 服務(wù)器用的域名去接入到 CDN 肯定會(huì)有問題的。

從后臺(tái)發(fā)過來一個(gè)json，和你本地保存一個(gè)json的區(qū)別：
1、前者有網(wǎng)絡(luò)傳輸消耗，當(dāng)然比后者慢一點(diǎn)
2、將來城市地名更新，前者只需修改后臺(tái)程序，后者需要重新打包前端程序。

綜上所述，我認(rèn)為的最佳方式是調(diào)用后臺(tái)接口獲取后，緩存在前端，前端程序退出的時(shí)候清空緩存

如果你直接寫在js里，可以省去解析json的時(shí)間（可以忽略不計(jì)）

docker可以做這個(gè)，自動(dòng)同步，

你需要的是搜索 移動(dòng)端適配方案
這個(gè)要講起來能寫幾千字，代碼不算
所以還是老老實(shí)實(shí)的看看相關(guān)文章吧
如果你只是具體的一小塊問題的話，還能給你詳細(xì)解答一下

看下network,是不是兩次都選了 if里else塊中的MC

你在componentWillReceiveProps方法中log一下，看看nextProps中究竟是什么，有沒有user這個(gè)對(duì)象？是不是nextProps.reducer.user

我覺得沒錯(cuò)啊 我生成的也是這樣
<selectKey resultType="java.lang.Integer" keyProperty="id" order="AFTER" >

配置
<generatedKey column="id" sqlStatement="SELECT LAST_INSERT_ID()" identity="true"/>

你建表的時(shí)候 主鍵有自增長(zhǎng)嗎

很正常啊，docker容器基礎(chǔ)鏡像和本地環(huán)境還是有差異的

報(bào)錯(cuò)就是環(huán)境里面沒有which命令

可以參考這個(gè)文檔看看，http://docs.upyun.com/cloud/s...
有其他問題也可以直接咨詢下售后

---模擬測(cè)試數(shù)據(jù)
;WITH test(post_no,tkt_no,[Zone],unit)AS(
   SELECT '710001','ZAA865286','A','N' UNION ALL
   SELECT '710630','ZAA865924','A','N' UNION ALL
   SELECT '710631','ZAB598749','B','N' UNION ALL
   SELECT '711261','ZAB599394','B','N' UNION ALL
   SELECT '711262','ZAC383493','C','N' UNION ALL
   SELECT '712987','ZAC385251','C','N' UNION ALL
   SELECT '720001','ZBA543954','D','C' UNION ALL
   SELECT '720407','ZBA865924','D','C' UNION ALL
   SELECT '720408','ZBB236123','E','C' UNION ALL
   SELECT '720512','ZBB236228','E','C' UNION ALL
   SELECT '720513','ZBC193757','F','C' UNION ALL
   SELECT '720645','ZBC193894','F','C'
)
/*
select min(post_no) +'~'+ max(post_no) as post_no, min(tkt_no) +char(10) + char(13) +  max(tkt_no) as tkt_no, [Zone], max(unit)
from TEST
group by zone
order by post_no
*/
select t.min_postno+1200*(sv.number-1) as StartNo,case when t.min_postno+1200*sv.number-1>=t.max_postno then t.max_postno else t.min_postno+1200*sv.number-1 end as EndNo
      ,row_number()over(order by t.groupid,sv.number) as BoxNo
      ,case when t.min_postno+1200*sv.number-1>=t.max_postno then t.max_postno else t.min_postno+1200*sv.number-1 end-(t.min_postno+1200*(sv.number-1))+1

from (
    select left(post_no,2) as groupid, min(post_no) as min_postno,max(post_no) as max_postno,CEILING((convert(int,max(post_no))-min(post_no)+1)/1200.0) as boxcount
    from test as t
    group by left(post_no,2)
) as t
inner join master.dbo.spt_values as sv on sv.type='P' and sv.number between 1 and t.boxcount

首先listView繼承于scrollView，scrollView又是繼承于view，view對(duì)于tap的響應(yīng)是有阻攔性的，不像web中的冒泡，所以滑動(dòng)沖突基本不存在 你試下就知道了。然后再說性能，沒有感覺到有什么性能差異，倒是全塞到listView的header里這個(gè)想法，不太好。無論是代碼可讀性還是代碼功能的職責(zé)行上都欠缺考慮

在option->configure里可以設(shè)置，微軟雅黑就可以了。

你可以參看這個(gè)鏈接Class:

https://github.com/matyhtf/framework/blob/master/libs/Swoole/Database/MySQL.php

他的做法是每次執(zhí)行完mysql_query后即使檢測(cè)返回值，如果mysql_query返回失敗，則再執(zhí)行一次mysql_connect，這樣可以確保下一次的請(qǐng)求正常。

c++中的at(x, y) 仍然將x, y轉(zhuǎn)換為int, 即取矩陣指定行列的值, 與python中常用的flow[x, y]相同, 但不知為什么c++和python的結(jié)果偏差很大, 或者是因?yàn)閜ython的值轉(zhuǎn)換為int類型的關(guān)系??

能把頁面截圖出來看看嗎，看起來的確很奇怪

可以多了解一些API

let target = document.getElementById('shouldGoTo');
let eventObj = document.createEvent('MouseEvents');
eventObj.initMouseEvent('click',true,true,window,1,12,345,7,220,false,false,true,false,0,null);
target.dispatchEvent(eventObj);