根據(jù)小數(shù)點(diǎn)位置固定與否，機(jī)器數(shù)又可以分為定點(diǎn)數(shù)和浮點(diǎn)數(shù)。
整數(shù)。認(rèn)為整數(shù)沒有小數(shù)部分，小數(shù)點(diǎn)固定在數(shù)的最右邊。

你理解反了。

計(jì)算機(jī)表示數(shù)有 2 種方式：定點(diǎn)數(shù)和浮點(diǎn)數(shù)。而這兩種方式都可以表示整數(shù)和小數(shù)。

所謂定點(diǎn)，就是小數(shù)點(diǎn)位置固定，如果固定在最右面，那么這個(gè)數(shù)就是整數(shù)。如果固定在最左邊，那么這個(gè)數(shù)就是 0 到 1 之間的小數(shù)。也可以固定在中間，例如固定在右面數(shù)第 3 位，那么就可以表示 2 位小數(shù)，例如：1.23，3.00，……

但是這樣表示小數(shù)有問題，就是表示范圍太小，精度由小數(shù)點(diǎn)右面的位數(shù)來決定。于是，為了表示更大的數(shù)(不僅僅是小數(shù))的范圍，我們不固定小數(shù)點(diǎn)的位置，而是根據(jù)這個(gè)數(shù)的大小來動態(tài)確定小數(shù)點(diǎn)的位置，由于小數(shù)點(diǎn)的位置是浮動的，所以我們稱之為浮點(diǎn)數(shù)（PS：浮點(diǎn)數(shù)也可以用來表示整數(shù)）。

我之前博客連載過兩篇關(guān)于浮點(diǎn)數(shù)的文章:

• 代碼之謎（四）- 浮點(diǎn)數(shù)（從驚訝到思考）
• 代碼之謎（五）- 浮點(diǎn)數(shù)（誰偷了你的精度？）

綜上：

• 定點(diǎn)數(shù)：無精度損失、表示范圍小
• 浮點(diǎn)數(shù)：有精度損失，表示范圍大

module不是這樣配置的

module: {
    rules: [
      {
        test: [/\.bmp$/, /\.gif$/, /\.jpe?g$/, /\.png$/],
        loader: require.resolve('url-loader'),
        options: {
          limit: 10000,
          name: 'static/media/[name].[hash:8].[ext]',
        },
      },
    ]
  }

第一層元素是rules

function getDirTree( inputPath, callback){
     let files = fs.readdirSync(inputPath)
     for(file of files){
         let filePath = inputPath + '/' + file;
         let fileState = fs.statSync(filePath);
         if(fileState.isDirectory()){ // 如果是目錄 遞歸
             getDirTree(filePath)
         }else{
             console.log(file)
         }
     }
     callback && callback.call();
}
getDirTree(rootPath, function(){
    console.log('end.....');
})

setter/getter方法

嚴(yán)格來講，這些東西都與部署無關(guān)，Laravel 不過是一個(gè) PHP 框架而已，Laravel 應(yīng)用的部署與常規(guī)項(xiàng)目的部署并沒區(qū)別，在服務(wù)器上只要有它需要的運(yùn)行環(huán)境即可，通常在服務(wù)器端根本不會存在以上的名稱環(huán)境。

那么上面的東西是啥？它們不過就是一個(gè)開發(fā)環(huán)境而已，就像你學(xué) PHP 的時(shí)候，開發(fā)環(huán)境集成包一個(gè)意思，你同樣有很多選擇，比如給 windows 用的 WampServer、PHPStudy 還有給 mac 環(huán)境使用的 XAMPP 等等，它們做的事情都是一樣的：創(chuàng)建一個(gè)有 PHP、mysql、nginx/apache 的運(yùn)行環(huán)境而已。

所有，laravel 官方只不過是給大家提供了不同環(huán)境下的集成開發(fā)環(huán)境，加速與統(tǒng)一你的開發(fā)環(huán)境，不必在環(huán)境這事兒上踩坑。

就是這樣。

POST請求，最好使用RequestBody + bean(json)的形式

你的控制器請求路徑就是/get_all_news并沒有.html后綴
所以你的ajax請求要以控制器為準(zhǔn)

這樣的鏈接后面一般都有一次性的Token,后臺驗(yàn)證后自動設(shè)置為登錄狀態(tài)，也有相應(yīng)的cookies設(shè)置。鏈接大概是這樣子的。
https://www.thesite.com/index?token=a6sd6afs68a8sd78a&otherparams...

我發(fā)現(xiàn)flask-appbuilder的API URL其實(shí)是由sqlalchemy導(dǎo)出的，專為其后臺網(wǎng)頁的AJAX目的而設(shè)計(jì)。所以不完全符合RESTFul的架構(gòu)。而flask-restful則是根據(jù)RESTFul而設(shè)計(jì)導(dǎo)出的，其路徑可以有用戶自定義。

一般來說，針對Web、Mobile、前端的API，還是有所差異的。差異在于Web是固定IP的，而Mobile和瀏覽器前端IP不定，甚至是隱藏IP。這導(dǎo)致三者間鎖定和鑒權(quán)方式不一致。Web鎖定domain/IP，瀏覽器鎖定Referrer，Mobile無法鎖定。此外，對于apiKey/apiSecret/nouce/signature/TLS，以及登陸用戶的username/password等信息都通過session/cookie進(jìn)行保存。

npm install vue-cli -g
如果還是未找到
vim /etc/profile
將vue-cli的路徑配置好

>>> import re
>>> p = re.compile('\d+')
>>> s = 'hello12 world334'
>>> re.sub('\d+', '', s)
'hello world'

util.showLoading('xxx') 返回的是 undefined ，當(dāng)然不能再調(diào)用 .bind(null) 。

報(bào)錯(cuò)信息講的很明確cross-origin frame跨域

外面多嵌套一層設(shè)置樣式，是不是可以解決

對于參數(shù)綁定為何可以避免SQL注入，建議題主可以了解一下，值得注意的是prepare語句只能解析一條SQL，下面摘要說明一下prepare的作用：
首先從mysql服務(wù)器執(zhí)行sql的過程開始講起，SQL執(zhí)行過程包括以下階段 詞法分析->語法分析->語義分析->執(zhí)行計(jì)劃優(yōu)化->執(zhí)行。詞法分析->語法分析這兩個(gè)階段我們稱之為硬解析。詞法分析識別sql中每個(gè)詞，語法分析解析SQL語句是否符合sql語法，并得到一棵語法樹（Lex）。對于只是參數(shù)不同，其他均相同的sql，它們執(zhí)行時(shí)間不同但硬解析的時(shí)間是相同的。而同一SQL隨著查詢數(shù)據(jù)的變化，多次查詢執(zhí)行時(shí)間可能不同，但硬解析的時(shí)間是不變的。對于sql執(zhí)行時(shí)間較短，sql硬解析的時(shí)間占總執(zhí)行時(shí)間的比率越高。而對于淘寶應(yīng)用的絕大多數(shù)事務(wù)型SQL，查詢都會走索引，執(zhí)行時(shí)間都比較短。因此淘寶應(yīng)用db sql硬解析占的比重較大。

Prepare的出現(xiàn)就是為了優(yōu)化硬解析的問題。Prepare在服務(wù)器端的執(zhí)行過程如下

1） Prepare 接收客戶端帶”?”的sql, 硬解析得到語法樹(stmt->Lex), 緩存在線程所在的preparestatement cache中。此cache是一個(gè)HASH MAP. Key為stmt->id. 然后返回客戶端stmt->id等信息。

2） Execute 接收客戶端stmt->id和參數(shù)等信息。注意這里客戶端不需要再發(fā)sql過來。服務(wù)器根據(jù)stmt->id在preparestatement cache中查找得到硬解析后的stmt, 并設(shè)置參數(shù)，就可以繼續(xù)后面的優(yōu)化和執(zhí)行了。

Prepare在execute階段可以節(jié)省硬解析的時(shí)間。如果sql只執(zhí)行一次，且以prepare的方式執(zhí)行，那么sql執(zhí)行需兩次與服務(wù)器交互（Prepare和execute）, 而以普通（非prepare）方式，只需要一次交互。這樣使用prepare帶來額外的網(wǎng)絡(luò)開銷，可能得不償失。我們再來看同一sql執(zhí)行多次的情況，比如以prepare方式執(zhí)行10次，那么只需要一次硬解析。這時(shí)候  額外的網(wǎng)絡(luò)開銷就顯得微乎其微了。因此prepare適用于頻繁執(zhí)行的SQL。

Prepare的另一個(gè)作用是防止sql注入，不過這個(gè)是在客戶端jdbc通過轉(zhuǎn)義實(shí)現(xiàn)的，跟服務(wù)器沒有關(guān)系。 

建議題主看下MySQL官方文檔（https://dev.mysql.com/doc/ref...）。什么？看不懂英文？試試百度翻譯吧：https://fanyi.baidu.com

<Router history={history}>
    <Switch>
        <Route />
        <Route />
    </Switch>
</Router>

請以后提問問題的時(shí)候把代碼以code的形式貼出來，不要直接上圖。
有些人很想回答你的問題，本來可以直接粘你的代碼改，結(jié)果你的是圖，就不想回答了。

換行判斷\n 呀

遇到同樣的問題 解決了嗎？

最后解決問題了
delete了再重新設(shè)置，應(yīng)該就是在insert的時(shí)候出了問題了，代碼本身沒問題的

Tag Aware Sharding可以達(dá)到你的目的，但是這樣到后期數(shù)據(jù)會不均衡，并不推薦這樣使用，還是盡可能讓它更均衡。