message 是傳入的 props ，和 state 的作用其實(shí)是類似的
這個(gè)例子舉的不是很好，#app 上綁定的是最外層的 Vue 實(shí)例，包在這個(gè)里面的都屬于他的自組件。

父子組件是相對(duì)的，不是絕對(duì)的。
例如下面的結(jié)構(gòu)，a，b，c 三個(gè) vue 組件，a 包含 b，b 又包含 c，這樣的話 b 又是 a 的子組件，又是 c 的父組件。
在 a.vue 中傳入的 data="data1" 就是傳入到 b.vue 的 props
類比你上面就好比 app 這個(gè)變量相當(dāng)于 a.vue 中的 vue 組件，b 相當(dāng)于 my-component 這個(gè)組件

// a.vue
<template>
    <p>aaaa</p>
    <vue-b data="data1"/>
</template>

// b.vue
<template>
    <p>bbbb</p>
    <vue-c data="data2"/>
</template>

// c.vue
<template>
    <p>cccc</p>
</template>

文件批量下載可以讓后端打zip包來(lái)下載，你這個(gè)hack方法一方面瀏覽器兼容性不一致，另一方面下載出來(lái)一堆文件用戶體驗(yàn)不是很好。如果不考慮這些問(wèn)題就直接使用500ms即可

同樓上，最好使用數(shù)組來(lái)組織你的結(jié)構(gòu)，確保遍歷的有序。

你可以看下你項(xiàng)目的編碼集時(shí)什么，還有指定maven 編譯時(shí)的編碼，maven默認(rèn)是gbk編譯

from collections import Counter

data = [['黑','1101'], ['黑','1101'], ['白','1201'], ['黑','1102']]

c1 = Counter(d[0] for d in data)
for k,v in c1.items():
    print(k, v)

c2 = Counter(''.join(d) for d in data)
for k, v in c2.items():
    print(k, v)

跨源數(shù)據(jù)存儲(chǔ)訪問(wèn)
存儲(chǔ)在瀏覽器中的數(shù)據(jù)，如localStorage和IndexedDB，以源進(jìn)行分割。每個(gè)源都擁有自己?jiǎn)为?dú)的存儲(chǔ)空間，一個(gè)源中的Javascript腳本不能對(duì)屬于其它源的數(shù)據(jù)進(jìn)行讀寫操作。

Cookies 使用不同的源定義方式。一個(gè)頁(yè)面可以為本域和任何父域設(shè)置cookie，只要是父域不是公共后綴（public suffix）即可。Firefox 和 Chrome 使用 Public Suffix List 決定一個(gè)域是否是一個(gè)公共后綴（public suffix）。Internet Explorer使用其自己的內(nèi)部方法來(lái)確定域是否是公共后綴。不管使用哪個(gè)協(xié)議（HTTP/HTTPS）或端口號(hào)，瀏覽器都允許給定的域以及其任何子域名(sub-domains) 訪問(wèn) cookie。設(shè)置 cookie 時(shí)，你可以使用Domain，Path，Secure，和Http-Only標(biāo)記來(lái)限定其訪問(wèn)性。讀取 cookie 時(shí)，不會(huì)知曉它的出處。 即使您僅使用安全的https連接，您看到的任何cookie都可能使用不安全的連接進(jìn)行設(shè)置。

所以是不能跨域

理由 阮一峰 瀏覽器同源政策及其規(guī)避方法

MDN Same-origin policy

可能是你的地址被人家給屏蔽了！我這邊使用命令wget www.snort.org 沒(méi)有任何問(wèn)題。。
而且你的上面的鏈接很清楚，Connection refused 連接被拒絕！
應(yīng)該不是你的電腦的問(wèn)題。

Google了一下，高分屏跟Retina屏是一個(gè)概念。
我按照移動(dòng)端Retina屏適配的經(jīng)驗(yàn)，應(yīng)該可以通過(guò)修改viewport的縮放來(lái)解決這個(gè)問(wèn)題。

首先明確一下要解決的問(wèn)題：

1. 如何區(qū)分高分屏還是普通屏；
2. 如何對(duì)高分屏進(jìn)行縮放。

解決方法

1. 獲取window.devicePixelRatio，也就是俗稱的dpr。值為1的是普通屏，大于1的是高分屏。

2. 設(shè)置meta標(biāo)簽：

   <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">

   其中，initial-scale為1/dpr。

最后，以上是基于移動(dòng)端Retina屏的經(jīng)驗(yàn)，能否適用于PC端我不清楚，也沒(méi)有相關(guān)設(shè)備進(jìn)行實(shí)踐。如果你使用這個(gè)方法能夠解決問(wèn)題希望能夠及時(shí)反饋?；蛘哂袆e的方法也希望能給我評(píng)論，長(zhǎng)長(zhǎng)見(jiàn)識(shí)。

參考資料

【移動(dòng)適配】一個(gè)像素的border怎么實(shí)現(xiàn)

你可以考慮react-saga。

火狐瀏覽器,#緩存機(jī)制的問(wèn)題,已經(jīng)自己解決勒

你把iframe src 的路徑換成和網(wǎng)頁(yè)域名一樣的。安卓微信瀏覽器就可以顯示iframe的內(nèi)容了。蘋果微信內(nèi)置瀏覽器卻不用考慮同源的問(wèn)題

df[df.isnull().values==True].drop_duplicates()

從Spirng 官方案例中摘取以下解決方案并相應(yīng)簡(jiǎn)化

Filter方式

@Configuration
public class MyConfiguration {

    @Bean
    public FilterRegistrationBean corsFilter() {
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        CorsConfiguration config = new CorsConfiguration();
        config.setAllowCredentials(true);
        config.addAllowedOrigin("http://domain1.com");
        config.addAllowedHeader("*");
        config.addAllowedMethod("*");
        source.registerCorsConfiguration("/**", config);
        FilterRegistrationBean bean = new FilterRegistrationBean(new CorsFilter(source));
        bean.setOrder(0);
        return bean;
    }
}

Global Config 方式

@Configuration
@EnableWebMvc
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**");
    }
}

header放行所有就不寫，method不寫的情況下支持GET 、 DELETE 、 POST有需要才添加，origin不寫就是放行所有。其余配置有不知道有什么作用，請(qǐng)移步官方文檔自己研究。

token是在瀏覽器中是以cookie存儲(chǔ)，所以你說(shuō)續(xù)簽，前端發(fā)http請(qǐng)求，就會(huì)默認(rèn)帶上cookie，那么后端你就可以拿到判斷這個(gè)token的時(shí)效性了，然后在response set-cookie更新就好；但是，如果用戶半天不操作了，如果你的token設(shè)置失效時(shí)間為十分鐘，那后端就無(wú)法更新token了，就必須重新登錄。

先別急著考慮針對(duì)不同版本的兼容問(wèn)題，Chromium 49來(lái)說(shuō)，常規(guī)的padding，margin樣式肯定沒(méi)什么兼容性問(wèn)題的，你應(yīng)該先看下自己的CSS代碼，是不是規(guī)范的寫法

這個(gè)技術(shù)問(wèn)題確實(shí)比較棘手
我想提供另一種思路
從產(chǎn)品和交互的角度來(lái)講

為什么會(huì)出現(xiàn)文本溢出的情況？

是否允許出現(xiàn)？

為什么不允許出現(xiàn)文本溢出？

如果不允許的話，可不可以換一種交互來(lái)避免這個(gè)問(wèn)題

我是這樣處理的，在app.js中實(shí)現(xiàn)一個(gè)方法來(lái)處理這種數(shù)據(jù)，比如處理登錄信息：

// app.js
App({
    //...
    setupLogin: function(data, cb) {
        if (data) {
            // 如果傳入了數(shù)據(jù)（比如初次登錄），就更新
            wx.setStorageSync('loginData', data)
        } else {
            // 如果沒(méi)有就從本地storage里取登錄信息
            data = wx.getStorageSync('loginData')
        }

        if (data && data != [] && data != "") {
            this.globalData.loginData = data
        } else {
            this.globalData.loginData = null
        }

        if (cb) {
            cb()
        }
    }
})

每次小程序加載的時(shí)候調(diào)用一次setupLogin，將數(shù)據(jù)保存在app.globalData里，這樣用到的時(shí)候獲取就更方便。在這里，我會(huì)根據(jù)app.globalData.loginData是否為null來(lái)判斷是否需要進(jìn)行登錄操作。

如果還需要處理其他類似的數(shù)據(jù)，也可以這樣做。

當(dāng)然，你也可以封裝一個(gè)方法，來(lái)專門實(shí)現(xiàn)這一連串操作。

添加第五條記錄

"text_terms" : [ { "term" : "西門子", "freq" : 1 } ]

must_not 查不出此條記錄來(lái) 于是知道原因

只要text_term中存在term不等于西門子的記錄 都能查出來(lái) 即使其中也有term等于西門子

正確的查詢方法

"query": { "bool":{ "must_not":{ "nested": {"path": "text_terms", "query": { "term": { "text_terms.term": "西門子" } } } } } }

即must_not應(yīng)該放在nested外面

補(bǔ)充：

• must_not 在 nested 內(nèi)部

curl 'http://localhost:9200/test/_validate/query?explain=true&pretty' -H 'Content-Type: application/json' -d'
{
"query": { "nested": {  "path": "text_terms", "query": { "bool": { "must_not": [{ "term": { "text_terms.term": "西門子" } }] } } } }
}
'

  "explanations" : [
    {
      "index" : "test",
      "valid" : true,
      "explanation" : "ToParentBlockJoinQuery (+(-text_terms.term:西門子 +*:*) #_type:__text_terms)"
    }
  ]

• must_not在nested外部

curl 'http://localhost:9200/test/_validate/query?explain=true&pretty' -H 'Content-Type: application/json' -d'
{
"query": { "bool":{ "must_not":{ "nested": {"path": "text_terms", "query": { "term": { "text_terms.term": "西門子" } } } } } }
}
'

  "explanations" : [
    {
      "index" : "test",
      "valid" : true,
      "explanation" : "+(-ToParentBlockJoinQuery (text_terms.term:西門子) +*:*) #DocValuesFieldExistsQuery [field=_primary_term]"
    }
  ]

這種問(wèn)題其實(shí)沒(méi)必要糾結(jié)。你一次過(guò)請(qǐng)求3個(gè)數(shù)據(jù)，但是用戶只看其中一個(gè)tab，那么另外兩個(gè)tab的請(qǐng)求是不是就是叫浪費(fèi)？
前端可以適當(dāng)做處理，切換tab的時(shí)候要是第一次進(jìn)來(lái)就做請(qǐng)求，如果第二次進(jìn)入同一個(gè)tab，那么可以根據(jù)邏輯不去做請(qǐng)求。
所謂的浪費(fèi)我的理解就是對(duì)數(shù)據(jù)庫(kù)的壓力，這方面可以通過(guò)數(shù)據(jù)緩存去解決，甚至使用集群方案，利用更多的機(jī)子去分擔(dān)壓力。
這只是我的看法

你第一個(gè)是非箭頭函數(shù)所以沒(méi)改變this的作用域，第二個(gè)用到了箭頭函數(shù)改變了this的作用域。