Git 多賬號配置

`$.ajax({

url:"http://localhost:3333/audio",
type:"post",

}).done(res=>{

const blob = new Blob([res],{type:"audio/mp3"});
const blobUrl = URL.createObjectURL(blob);
const audio = new Audio(blobUrl);
audio.play();

});`

以上答案從我對其他的問題拷貝過來的，原理是一樣的。以音頻為例 type換成你的文件類型 比如pdf就是application/pdf
url換成你自己的

主要知識點就是blob和URL.createObjectUR

如果是遠程登陸，有可能遠程主機被禁止訪問。本地登陸說明密碼確實錯了

mysql有幾種不同長度的text

TINYBLOB, TINYTEXT       L + 1 bytes, where L < 2^8    (255 Bytes)
BLOB, TEXT               L + 2 bytes, where L < 2^16   (64 Kibibytes)
MEDIUMBLOB, MEDIUMTEXT   L + 3 bytes, where L < 2^24   (16 Mebibytes)
LONGBLOB, LONGTEXT       L + 4 bytes, where L < 2^32   (4 Gibibytes)

首先，你沒有代碼發(fā)出來，如果是代碼問題，那么就沒辦法分析。

公司里面的mysql好像有問題，我回家試了一下，沒有發(fā)生這種詭異的事件

設(shè)置不了吧，你的數(shù)據(jù)庫同表同字段能設(shè)置不同的默認值？

如果有err代表本來就沒寫成功，直接做下面的事情就好了。
最佳實踐是在這里至少應(yīng)該記錄一條日志，不能靜默地吞掉錯誤什么都不說，會對你將來調(diào)試問題造成很大困擾。

并發(fā)寫入嘛？
插入數(shù)據(jù)前判斷數(shù)據(jù)存在，用悲觀鎖，語法：select * for update
字段要加上索引，因為MySQL的行鎖是基于索引的

//大概這樣，只是個大概：
if($supplier !==0 ){ //當供應(yīng)商不為0時，goods_id使用供應(yīng)商的goods_id

    $where = 'goods_id=supplier_goods';

}else($dealer !== 0){ //當經(jīng)銷商不為0時，goods_id使用經(jīng)銷商的goods_id

    $where = 'goods_id=dealer_goods'; 

}
$data = $mysql->query("select * from table where {$where}");
建議將判斷邏輯放在前面，讓SQL一目了然

npm init會初始化你的項目，就是里面什么都沒有，你需要重新下載項目
然后 npm install
再 npm start

一個簡單的測試辦法：

1. 下載Postman( https://www.getpostman.com )
2. 發(fā)送請求(對方絕對不會說沒有收到請求了)
3. 如果2成功了，拷貝Postman自動生成的curl代碼。
4. 如果此代碼在服務(wù)器上依然不能成功，那就是服務(wù)器設(shè)置的問題。反之，就是代碼的問題。

為啥不用一個表搞定 user_id(用戶id),msg(消息)....(其他字段),is_read(是否已讀)。
全部消息：user_id = XXX
未讀：user_id=XXX and is_read = 0
已讀：user_id=XXX and is_read = 1
一鍵忽略: update is_read = 1 where user_id=XXX and is_read = 0

事件委托同級元素通過判斷屬性加以阻止，父級元素通過組織冒泡加以阻止。

1.match2的條件 這個None是啥意思，如果是想查詢consume這個字段是否存在，可以改成

{'$match': {'consume': {$exist:true}}}

2.這種優(yōu)化，我曾經(jīng)問過專業(yè)的大神@Mongoing中文社區(qū),我來班門弄斧一下，你這種查詢我猜測會很慢，但是慢的原因不在于match寫得有問題，而是lookup太慢了，十分影響效率，mongodb是非關(guān)系型數(shù)據(jù)庫，本身設(shè)計就不想要關(guān)系(我猜的哈)，所以lookup和其它查詢關(guān)系的并不是它的強項，而且你這里查詢的是消費記錄和充值記錄，這兩個完全是可能不會更改的數(shù)據(jù)，所以我建議是更改數(shù)據(jù)結(jié)構(gòu)，將consume和recharge直接存放在這個user下面，然后不用lookup，直接篩選就可以了，這樣絕對會很快，當然這前提是在業(yè)務(wù)允許的情況下，修改數(shù)據(jù)結(jié)構(gòu)。
下面貼出我大哥的回答
mongodb的關(guān)聯(lián)查詢$lookup
ps：而且我做過一個實驗，20條數(shù)據(jù)都要lookup的情況下，我查兩次數(shù)據(jù)庫(先查出lookup之前的數(shù)據(jù)，再用lookup的根據(jù)(比如說_id)去再查一次數(shù)據(jù)庫，再把這兩者的結(jié)果整合成我想要的數(shù)據(jù))都比直接lookup要快。。。。

你可能需要ObjectId(_id);

router.delete('/api/comment', (req, res, next) => {
    const { _id, postID } = req.body;
    commentModel.remove({ _id }, (err, doc) => {
        if (err) {
            res.json({ code: 1, msg: err });
        } else {
            // 更新文章的comments列表
            postModel.update({ Object(_id): postID }, { $pull: { comments: _id } }, (err, postDoc) => {
                res.json({ code: 0, data: doc });
            });
        }
    });
});

直覺，你都沒貼報錯還有返回，就只能這樣了

Authorization 了解一下

可能你看的例子寫得就不正確。
從設(shè)計的角度講你的session跟db.col集合沒有任何關(guān)聯(lián)，系統(tǒng)怎么會知道這個session怎么會作用于這個集合上呢？真實環(huán)境中會有多個session，多個集合，系統(tǒng)必須有一定的方法來知道對應(yīng)關(guān)系，所以現(xiàn)在的寫法肯定是欠妥的。正確的寫法是：

s = db.getMongo().startSession();
s.startTransaction();
s.getDatabase("<database>").col.insert({name: 'mongo'});
s.abortTransaction();
db.col.find();

事實上在你commit之前都不應(yīng)該在集合中查詢到新插入記錄。所以之前的寫法這點就已經(jīng)不吻合了。
更多實例參考MongoDB官方文檔：Session.startTransaction

你好 我想咨詢一下 我開啟了think queue:listen之后 電腦就變得特別卡 是因為我服務(wù)器的配置太低了么

ascii('ok') ascii(col_name)