在线观看不卡亚洲电影_亚洲妓女99综合网_91青青青亚洲娱乐在线观看_日韩无码高清综合久久

ajax請(qǐng)求用dataType: 'html'

Number是沒有replace方法的，你這個(gè)只支持String類型:value.toString().replace(/^(-)?(\d+)\.(\d\d)(.*)$/,'$1$2.$3').

--逆向思維，那我們就先查出這三個(gè)字段都不含8的數(shù)據(jù)
--再查詢的時(shí)候不包含它們即可

SELECT Id,mobile1,mobile2,mobile3 FROM [Table]

WHERE Id NOT IN
        (
            SELECT Id FROM [Table] 

            WHERE mobile1<>8 AND mobile1<>8 AND mobile1<>8
         )

headless chrome不支持flash plugin。詳情見：https://bugs.chromium.org/p/c...

function unique(arr) {

const res = new Map();
return arr.filter((a) => !res.has(a.name) && res.set(a.name, 1))

}

你的每個(gè)選項(xiàng)是for循環(huán)渲染出來的吧，那么正確答案的選項(xiàng)也是知道的。

/*每個(gè)選項(xiàng)綁定的樣式*/
<div v-for="(item, index) in question">
    <div :class="bindClass" @click="clickItem(index)"></div>
</div>

data() {
    return {
        question: [...],
        bindClass: '' //未選擇的時(shí)候
    }
}
/*點(diǎn)擊選項(xiàng)時(shí)的點(diǎn)擊事件*/
clickItem(index) {
    if(question[index]===正確答案){
        bindClass = correctClass //答對(duì)的樣式
    }else {
        bindClass = errorClass /答錯(cuò)的樣式
    }
}

但我不知道你一道題返回的數(shù)據(jù)格式是什么樣子的，你可以大概看看這種思路是否可行？

你可以從插件里搜一下中文包
Chinese (Simplified) Language Pack for Visual Studio Code

一次for循環(huán)結(jié)束，常量b的生命周期就結(jié)束了，下一次for循環(huán)的時(shí)候，又new了一個(gè)新的常量b

這個(gè)彈窗是在開發(fā)工具才出現(xiàn)的，真機(jī)上的話會(huì)出現(xiàn)另一種彈窗，用戶拒絕的話會(huì)返回相關(guān)錯(cuò)誤

或許你先可以了解一下F12的用處。

renderFunc(h, option) {
    return h('span', `${option.key} - ${option.label} `);
}

按你的意思是每個(gè)任務(wù)的狀態(tài)全是會(huì)變成完成的是嗎？
假設(shè)你的監(jiān)聽函數(shù)監(jiān)聽的是State這個(gè)變量，那么在每個(gè)任務(wù)結(jié)束是判斷下這個(gè)變量的值來決定是否退出。

async function t(){
    const T=[A,B];
    for(let i=0;i<T.length;i++){
        await T[i].run();
        // 假設(shè)失敗會(huì)改成`failed`
        if(State=="failed"){
            console.log("隊(duì)列任務(wù)失敗");
            break;
        }
    }
}

說下自己的理解，供參考。假設(shè)題主了解網(wǎng)絡(luò)編程和計(jì)算機(jī)系統(tǒng)的一些基本概念。

簡單概括來說，事件驅(qū)動(dòng)是實(shí)現(xiàn)并發(fā)處理的一種方式。

我們就以HTTP請(qǐng)求的處理過程為例，為簡化說明，僅考慮網(wǎng)絡(luò)IO，不考慮文件IO和數(shù)據(jù)庫等其他過程，也不考慮多核系統(tǒng)。
考慮采用如下最簡模型來處理HTTP請(qǐng)求：

main_loop:
  accept() 
  recv()  
  parse() 
  send() 
  close() 

來一個(gè)連接，讀取數(shù)據(jù)（請(qǐng)求），解析請(qǐng)求內(nèi)容，返回?cái)?shù)據(jù)（應(yīng)答）。
同一時(shí)間只為一個(gè)客戶端服務(wù)。在為A客戶端服務(wù)的過程中，B客戶端必須等待。

這種方式非常簡單直接，容易理解，但其無法滿足現(xiàn)實(shí)場景的需要——不支持并發(fā)。
現(xiàn)實(shí)中，客戶端的請(qǐng)求是并發(fā)的：即當(dāng)一個(gè)客戶端的請(qǐng)求還在處理時(shí)，另外一個(gè)客戶端的請(qǐng)求就會(huì)達(dá)到，甚至多個(gè)客戶端的請(qǐng)求同時(shí)達(dá)到。
而且，recv 和 send等涉及網(wǎng)絡(luò)操作的API由于網(wǎng)絡(luò)數(shù)據(jù)發(fā)送與到達(dá)的不確定性，可能需要等待，CPU會(huì)空閑下來——但這種模型下即使CPU空閑了也無法處理其他客戶端的請(qǐng)求，浪費(fèi)了CPU。

我們采用如下多線程模型，可以解決上述問題：

main_loop:
  accept() 
  start_thread(thread_loop)

thread_loop:    
    recv()  
    parse() 
    send() 
    close() 
    exit thread()

即每個(gè)客戶端在一個(gè)獨(dú)立的線程中處理。
當(dāng)一個(gè)客戶端的線程執(zhí)行網(wǎng)絡(luò)操作需要等待時(shí)，會(huì)被操作系統(tǒng)調(diào)度出去，執(zhí)行其他需要干活兒的線程。
似乎完美了解決了我們的問題？
然而并沒有。
因?yàn)椴僮飨到y(tǒng)創(chuàng)建線程的開銷是比較大的，能夠支持的線程數(shù)量是有限的，通常是幾萬的級(jí)別，如果線程太多，就會(huì)有很多的CPU浪費(fèi)在了線程的創(chuàng)建、銷毀、調(diào)度等管理操作上。

所以為了充分發(fā)揮CPU的能力，支持更多的并發(fā)數(shù)量，，在Linux上有另外一種處理并發(fā)的方式：
內(nèi)核提供了監(jiān)聽大量網(wǎng)絡(luò)連接（句柄）可讀、可寫等事件的機(jī)制和接口。
應(yīng)用把需要監(jiān)聽對(duì)象以及關(guān)心的事件注冊(cè)給內(nèi)核，內(nèi)核在有事件達(dá)到時(shí)通知應(yīng)用處理。
基于這種機(jī)制處理并發(fā)就是事件驅(qū)動(dòng)。

事件驅(qū)動(dòng)機(jī)制的基本模型是：

create_listen_socket()
register_event_for_listen_socket()
main_loop:
    wait_for_event()
    check_events:
         if listen_socket has event(new client coming) :
               accept()
               register_event_for_client_socket()
        if client_socket has event(new data coming):
               recv()                       
               parse()
               send()              

但這里有一個(gè)問題，有可能一個(gè)客戶端剛讀取了一部分?jǐn)?shù)據(jù)，就沒了，剩下的還在網(wǎng)絡(luò)中沒過來，需要繼續(xù)等待。
這就需要把當(dāng)前的讀取內(nèi)容和請(qǐng)求處理狀態(tài)（也即上下文）保存起來，繼續(xù)處理其他客戶端的事件。
然后下次這個(gè)客戶端再有事件到來時(shí)再找回上下文繼續(xù)處理。
這其實(shí)需要應(yīng)用自己做一些任務(wù)調(diào)度相關(guān)的上下文保存和切換工作。

當(dāng)使用多線程處理并發(fā)時(shí)，操作系統(tǒng)幫我們做了這些工作，我們無需關(guān)心任務(wù)切換。
因?yàn)橐粋€(gè)線程就只處理一個(gè)客戶端，反復(fù)調(diào)用recv把一個(gè)請(qǐng)求的數(shù)據(jù)讀完然后解析處理就可以了，也不用擔(dān)心沒數(shù)據(jù)到來時(shí)，recv阻塞了其他客戶端的處理。
所以多線程編寫并發(fā)代碼非常簡單直接。

如上，事件驅(qū)動(dòng)機(jī)制是Linux上解決并發(fā)問題的一種高效編程模型。
應(yīng)用反復(fù)探測事件，對(duì)接收到的事件進(jìn)行逐個(gè)處理的過程就是事件循環(huán)。

那么同步和異步概念體現(xiàn)在哪里呢？

所謂同步就是我們執(zhí)行一個(gè)任務(wù)，一直等待任務(wù)執(zhí)行結(jié)束。
所謂異步就是我們執(zhí)行一個(gè)任務(wù)，不等待任務(wù)執(zhí)行結(jié)束，繼續(xù)去干其他活兒，任務(wù)結(jié)果后有個(gè)通知，或者干脆不關(guān)心任務(wù)的執(zhí)行結(jié)果。

在多線程模型中，每接收到一個(gè)新的客戶端就創(chuàng)建一個(gè)線程處理，這就是一種異步處理。
在事件驅(qū)動(dòng)模型中，當(dāng)沒有數(shù)據(jù)可讀時(shí)，就把這個(gè)客戶端繼續(xù)放到監(jiān)聽隊(duì)列中監(jiān)聽，也是一種異步。

如果我們考慮文件IO，把IO請(qǐng)求丟給另外一個(gè)或一組線程（線程池）處理，處理完后通知主線程，也是一種異步。

看看scope.row.createTime有沒有問題。

Axios 不是有個(gè) baseURL

const service = axios.create({
  baseURL: process.env.baseURL, // api的baseURL
  timeout: 5000 // 請(qǐng)求超時(shí)時(shí)間
})

可以根據(jù) NODE_ENV 來判斷生產(chǎn) 開發(fā) 還是 測試 自動(dòng)切換url

module.exports = {
  NODE_ENV: '"production"',
  baseURL:'"xxxxxxxxx"'
}

動(dòng)畫不會(huì)只能給靜態(tài)樣式。

background: -webkit-radial-gradient(
        rgba(255,0,0,1) 0px,
        rgba(255,0,0,1) 10px, 
        rgba(255,0,0,.8) 10px,
        rgba(255,0,0,.6) 20px,
        rgba(255,0,0,1) 20px,
        rgba(255,0,0,1) 22px,
        rgba(255,0,0,.7) 22px,
        rgba(255,0,0,.7) 60px,
        rgba(255,0,0,1) 60px,
        rgba(255,0,0,1) 62px,
        rgba(255,0,0,.7) 62px,
        rgba(255,0,0,.5) 100px,
        rgba(255,0,0,1) 100px,
        rgba(255,0,0,1) 102px,
        rgba(255,0,0,.3) 102px,
        rgba(255,0,0,.3) 110px,
        rgba(255,0,0,1) 110px,
        rgba(255,0,0,1) 112px,
        rgba(255,0,0,.3) 112px,
        white 120px,
        white);

https://jsfiddle.net/3L6q0w5L/

一般來說是你依賴得某個(gè)模塊有安全問題，升級(jí)一下那個(gè)模塊就好了

1. 看官方文檔：wx.navigateTo(OBJECT)
2. 需要跳轉(zhuǎn)的應(yīng)為非 tabBar 的頁面的路徑，

.mint-tabbar{

.mint-tab-item{
  .mint-tab-item-label{
    font-size: 100px;
  }
}

}