鍍金池/ 問答/ 網(wǎng)絡(luò)安全問答
若相惜 回答

1.是不是網(wǎng)絡(luò)傳輸?shù)倪^程慢可以記錄一下前端發(fā)送請求的時間，后端接收到請求的時間，比一下看看，有多少差距，正常來說150K的表單不會影響請求速度的，如果這個都會影響，那文件上傳怎么辦

故林 回答

如果一個用戶只屬于一個組,那么用戶給個屬性標(biāo)記為是否組長就可以了.
如果一個用戶屬于多個組,那么組記錄下設(shè)置組長信息,保存對應(yīng)用戶id,這樣只是一對一.
互為一對多,肯定不行

忘了我 回答

clipboard.png
table的row-class-name使用方法，根據(jù)selection計算選中行的className

監(jiān)聽SelectionChange事件，修改selection數(shù)組，
然后用doLayout重繪圖表，應(yīng)該可行

影魅 回答

不是默認(rèn)只能選擇日期，不能輸入呀

柚稚 回答

HTTP 協(xié)議規(guī)定了 GET、POST 這些請求方式，但是同時要注意的是，這些方式本身是含有語義的。

GET 很好理解就是獲取的意思。
一般來說 POST 理解為創(chuàng)建資源，PUT 理解為更新資源。

HTTP 協(xié)議本身就是在通過 URL 表示資源的映射，用請求方式來表示對資源的操作（包括但不限于創(chuàng)建、刪除、更新、查找，也就是 CRUD)，用 HTTP 狀態(tài)碼 表示操作的結(jié)果。

而 RESTful 的重點其實在于如何建立資源與 URL 的映射，它只是一個規(guī)范，告訴你什么算一個（符合它理念的）好的設(shè)計，它并不嚴(yán)格規(guī)定所有東西。

以上僅為個人理解，如有錯誤還請不吝賜教！

冷溫柔 回答

不能在回調(diào)里設(shè)ctx.body，回調(diào)的時候請求已經(jīng)返回了，用async/await吧。

一個類似的問題：https://segmentfault.com/q/10...

替身 回答

嗯吶，嚴(yán)格模式下指向undefined。非嚴(yán)格模式下指向window，至于為什么指向window就是個老生常談的問題了。

this的指向是運行時綁定。何為運行時，指的就是函數(shù)的調(diào)用點在哪里。很顯然，foo()的調(diào)用點在全局，所以this便指向全局對象或者undefined。

可供參考

瞄小懶 回答

我遇到過類似問題：頁面多 <input /> 交替 focus 鍵盤大概率無法劃出，在問題機型原生瀏覽器測試無該現(xiàn)象

分析原因：<input /> 獲取焦點不靈敏

解決方案：<input /> 父元素 on-click 時強制 input.focus()

測試機型：Iphone 6s

問題機型：Iphone 6s（11.4.1）

慢半拍 回答

1。個人覺得localhost能不能用沒有什么關(guān)系
2?？梢韵葯z查本地hosts設(shè)置，localhost要解析到127.0.0.1
3。了解一下docker吧，開發(fā)環(huán)境還要搞這么多東西干嘛。
4。斷開網(wǎng)線試一下

汐顏 回答

我一般是 resolve (a problem) 的觀點。

因為像 這個決策、參數(shù)、過程比較復(fù)雜，需要抽象出來 這一類問題，需要有個東西來提供這個復(fù)雜實現(xiàn)，Provider 顯然是不合適的因為它一般提供的是實體，那么就可以用 resolve 來表示這個東西是為了解決問題而存在的。

還有一種常見情況是用于解析給定參數(shù)的，比如把一個 HTTP 請求里的 query 或是 payload 部分解析到一個 POJO(我是搞 Java 的)或什么結(jié)構(gòu)里時，這個解析過程可以稱為 resolve（也就是 使分解 這個意思），不過如果用更高的視角去看待這個問題的話，跟上邊說的其實也相通。

以上僅為個人觀點，因為的確也不是經(jīng)常用到這個寫法，如有錯誤還請指教。

淺淺 回答

異常分 3 種情況:

  1. 協(xié)調(diào)者不宕機，參與者宕機；
  2. 協(xié)調(diào)者宕機，參與者不宕機；
  3. 協(xié)調(diào)者宕機，參與者也宕機；

對于（1），當(dāng)在事務(wù)進(jìn)行過程中，有參與者宕機時，他重啟以后，可以通過詢問其他參與者或者協(xié)調(diào)者，從而知道這個事務(wù)到底提交了沒有。

對于（2），協(xié)調(diào)者宕機后，可以起新的協(xié)調(diào)者，然后查詢所有參與者的狀態(tài)是否有 commit 的，如果有，則繼續(xù) commit，如果都沒有，則 abort。

對于（3），是唯一 2PC 不能解決的：當(dāng)協(xié)調(diào)者在發(fā)出 commit 消息后宕機了，而唯一收到這條命令的一個參與者也宕機了，這個時候這個事務(wù)就處于一個未知的狀態(tài)，沒有人知道這個事務(wù)到底是提交了還是未提交，從而需要數(shù)據(jù)庫管理員的介入，防止數(shù)據(jù)庫進(jìn)入一個不一致的狀態(tài)。當(dāng)然，如果有一個前提是：所有節(jié)點或者網(wǎng)絡(luò)的異常最終都會恢復(fù)，那么這個問題就不存在了，協(xié)調(diào)者和參與者最終會重啟，其他節(jié)點也最終也會收到commit T的信息。

妖妖 回答

假設(shè)另一個header組件是AnotherHeader
mainroute.js中這樣寫

const MainRoute = () => (
    <Router>
        <Switch>
            {/*<Route exact path="/" component={Index}/>*/}
            {條件 ? <Header/> : <AnotherHeader>}
            <TopBar/>
            {routes.map((route, i) => <RouteWithSubRoutes key={i} {...route} />)}
        </Switch>
    </Router>
);

其中條件為true顯示Header組件,false則顯示AnotherHeader,不知道理解的對不對，望有效

別瞎鬧 回答

volatile僅保證可見性。這個可見性是針對讀取操作來說的，所以你說的情況完全有可能發(fā)生。

之所以會這樣，是因為對個線程并發(fā)對同一個變量進(jìn)行修改時，除了可見性，還必須保證修改過程是原子的，修改過程包括讀、自增、寫三步。

所以你這種情況，如果把inc換成AtomicInteger就沒問題了。

如果你的10個線程中，只有1個線程會修改inc變量，另外9個線程都只是讀取，那么就可以使用volatile，它會保證這9個線程每次讀到的都是最新的inc值。

亮瞎她 回答 
$me = $response->getGraphUser();
$pictureJson = $me->getPicture();
$pictureItem = json_decode($pictureJson,true);
echo $pictureItem['url'];

大概就是把這個json字符串轉(zhuǎn)換成PHP數(shù)組。然后再處理。

吢丕 回答
已經(jīng)自己看著文檔實現(xiàn)了!
汐顏 回答

RN里面也有l(wèi)ayoutAnimation
例如這個效果：
https://blog.csdn.net/u014041...

首頁 上一頁 262 263 264 265 266 267 268 269 270 下一頁 尾頁