load->help() 實(shí)現(xiàn)起來會(huì)強(qiáng)耦合,我給你以下倆個(gè)建議，僅供參考

1、使用ci內(nèi)置方法，load->library 去加載微信支付的核心sdk
2、使用composer工具擴(kuò)展ci本身對(duì)框架的局限，在官方packagist找到一個(gè)你需要的第三方微信支付的包

當(dāng)然可以，你要添加掛載參數(shù) noserverino。

請(qǐng)參考 https://serverfault.com/quest...

segmentfault也是問答平臺(tái)，也可以解決你的問題。而且，stack overflow都是英文交流，很懷疑你怎么提問題。如果用中文提，sf適合你

前后端分離后，如果是不同的團(tuán)隊(duì)維護(hù)，可以考慮前端頁面部署在獨(dú)立的服務(wù)器上，當(dāng)然需要先解決跨域訪問的問題。

不知道樓主需要的是不是這樣的，希望對(duì)你有幫助。。。

不能刪除，自問自答...

$schedule->call('App\Service\DataService1@syncData')->hourly();
$schedule->call('App\Service\DataService2@syncData')->dailyAt(00:01);

即可。

$a = 1 || $b = 1 可以看成 $a = （1 || $b = 1），$a = true;
對(duì)PHP不熟，但是如果你自己實(shí)現(xiàn)過四則運(yùn)算，這問題其實(shí)很簡(jiǎn)單。：）

單純的顏色轉(zhuǎn)換用canvas可以實(shí)現(xiàn)。

但是我覺得更難的地方在于如何判斷出需要轉(zhuǎn)換的顏色，也就是識(shí)別問題。

以你的圖為例，人一眼能看出來是把路由器的白色變成了其他顏色，可是在實(shí)際代碼中需要有一個(gè)明確的顏色值來決定是否轉(zhuǎn)換，這個(gè)值不可能是用戶提供的，只能靠自己去判斷，也就是自己去找出這個(gè)白色的顏色值。

可以靠面積，但是這可能跟背景沖突。

可以靠形狀，這樣難度就上升了幾個(gè)數(shù)量級(jí)。

實(shí)際情況中需要替換的顏色不一定是同一個(gè)值，有可能受光照、陰影等影響，會(huì)造成細(xì)微的顏色差別，這也是要考慮的。

完整地把這一套實(shí)現(xiàn)下來，可能就相當(dāng)于一個(gè)小型美顏算法了。看起來這也是個(gè)邊角需求，可以去找找開源實(shí)現(xiàn)，節(jié)省一些力氣。

因?yàn)?GFW ，找個(gè)代理服務(wù)器，設(shè)置下代理就好了。如果有vpn，就掛上vpn再去下載。

先file_get_contents到網(wǎng)站html內(nèi)容，然后使用preg_match,preg_match_all匹配就可以了。為什么需要框架。
比如抓微信文章(我隨便敲的)：

   $file = file_get_contents($url);
        $article = [];
        //文章標(biāo)題
        preg_match('/<title>(.*?)<\/title>/', $file, $title);
        $article[ 'title' ] = $title ? $title[ 1 ] : '';
        //文章正文
        preg_match('/<div class="rich_media_content " id="js_content">[\s\S]*?<\/div>/', $file, $content);
        

1. 設(shè)置數(shù)據(jù)字段的類型為 LONGBLOG, 大小為4G
2. base64_decode, 然后生成個(gè)文件名, 保存起來即可.

相當(dāng)于給struct中的字段添加了tag屬性，可以通過reflect包來獲取struct中字段的屬性

將變量用 json_encode后輸出
類似 var days=<?=json_encode($days)?>;

不是babel-poyfill的問題，是你的babel就沒有配置對(duì)，檢查一下babel和es2015等等的配置，因?yàn)槟愕募^函數(shù)都沒有轉(zhuǎn)換，這是babel的問題，是js語法就沒有被轉(zhuǎn)換

es6的object.values方法，直接轉(zhuǎn)換成數(shù)組

hanging-punctuation好像可以控制，沒測(cè)試過，不過除了mac并不兼容所以沒什么意義
非要滿格顯示有個(gè)取巧的辦法是用text-align: justify;，但是可能還不如默認(rèn)的美觀

找到了答案

在model類中，添加一下成員變量即可：

    //定義字段類型
    protected $casts = [
        'columnName' => 'string'
    ];

如果評(píng)論里的邏輯是對(duì)的。應(yīng)該做有改無增的操作，而id不同的時(shí)候你并沒有push。

// 簡(jiǎn)化版本
var miniCartListArr = []
var miniId = {}
function dataHandler (opt) {
    if (miniId[opt.skuId] !== undefined) {
        // 有改
        miniCartListArr[miniId[opt.skuId]] = opt
    } else {
        // 無增
        // 存 id:索引，方便下次有改
        miniId[opt.skuId] = miniCartListArr.length
        miniCartListArr.push(opt)
    }
}

arr2 = [...arr1]
這么寫并不是個(gè)真的深拷貝。

var arr1 = [{name:1}]
arr2 = [...arr1]
arr2[0].name = 2
arr1[0].name // 1
arr1 === arr2 //false
arr1[0] === arr2[0] //true

個(gè)人一些看法：（什么語言都差不多的，我這邊是Java的）

省略前頭的部分內(nèi)容，畢竟是比較簡(jiǎn)單的演化過程

我們將session做成一個(gè)session服務(wù)器，browser1通過負(fù)載均衡請(qǐng)求服務(wù)器，服務(wù)器將session信息存儲(chǔ)到session服務(wù)器中，當(dāng)想要獲取時(shí)就反向進(jìn)行。（缺點(diǎn)：目前session Server是單點(diǎn)的，如何解決單點(diǎn)，保證可用性）

我們可以將Session Server也做成集群，其適合用于Session數(shù)量與web服務(wù)數(shù)量大的情況下，更改架構(gòu)后，也要修改應(yīng)用存儲(chǔ)session的業(yè)務(wù)邏輯。

接下來我們?cè)倏纯磾?shù)據(jù)庫，讀寫都要經(jīng)過數(shù)據(jù)庫，當(dāng)用戶量達(dá)到一定量時(shí)，數(shù)據(jù)庫又將成為一個(gè)瓶頸，則我們將如何解決？我們可以使用數(shù)據(jù)庫的讀寫分離，主從庫，并通過統(tǒng)一的數(shù)據(jù)訪問模型進(jìn)行訪問，將所有讀操作引入到Slave服務(wù)器，將寫操作引入到主庫當(dāng)中，由于數(shù)據(jù)庫讀寫分離，所以應(yīng)用程序也要有相應(yīng)的變化，使用數(shù)據(jù)訪問模塊讓應(yīng)用程序開發(fā)人員不用理會(huì)讀寫分離的存在，這樣多數(shù)據(jù)源讀寫代碼對(duì)我們的業(yè)務(wù)就沒有了侵入（代碼層的演變，如何支持多數(shù)據(jù)源、如何封裝對(duì)業(yè)務(wù)沒有侵入、如何使用現(xiàn)用的ORM框架實(shí)現(xiàn)數(shù)據(jù)讀寫分離、是否更換ORM、其優(yōu)缺點(diǎn)？）

當(dāng)我們?cè)L問過大，I/O過大，我們數(shù)據(jù)的讀寫分離又將遇到這幾個(gè)問題，主從庫復(fù)制時(shí)是否延遲（分機(jī)房部署、跨機(jī)房傳輸），應(yīng)用對(duì)于數(shù)據(jù)源的路由問題，接著我們?yōu)榱颂岣叻?wù)器，增加了CND和反向代理服務(wù)器，使用CDN可以解決不同地方訪問速度問題、反向代理可以在機(jī)房中緩存用戶的資源。

這時(shí)文件服務(wù)器又出現(xiàn)了瓶頸，我們將文件服務(wù)器改為分布式文件服務(wù)器集群，我們要考慮到：如何不影響線上的業(yè)務(wù)訪問，是否需要業(yè)務(wù)部門幫忙清理數(shù)據(jù)，是否需要備份服務(wù)器，是否需要重新做域名解析。

這時(shí)我們的數(shù)據(jù)庫又出現(xiàn)了新的瓶頸，我們選擇專庫專用的方式，進(jìn)行數(shù)據(jù)庫的垂直拆分，可以解決寫數(shù)據(jù)、并發(fā)、量大的問題，分庫后又將帶來一些新的問題：跨業(yè)務(wù)的事務(wù)（分布式事務(wù)）

當(dāng)某個(gè)數(shù)據(jù)的訪問量、數(shù)據(jù)量、日志等過大達(dá)到瓶頸時(shí)，這時(shí)我們就要進(jìn)行數(shù)據(jù)庫的水平拆分，我們將User拆分成Users1和Users2，水平拆分即將同一個(gè)數(shù)據(jù)表的數(shù)據(jù)拆分到兩個(gè)數(shù)據(jù)庫當(dāng)中，這時(shí)我們就解決了單數(shù)據(jù)庫的瓶頸。

水平拆分后，SQL路由出現(xiàn)一些問題，假設(shè)我們想知道某個(gè)用戶是存在Users1還是Users2中，且由于分庫，主鍵的策略也將有所不同，同時(shí)也將面臨一個(gè)分頁的問題（后臺(tái)管理系統(tǒng)在進(jìn)行展示時(shí)還要考慮分頁的問題），當(dāng)完成后，我們又發(fā)現(xiàn)應(yīng)用服務(wù)器的搜索量上升，這時(shí)我們將應(yīng)用服務(wù)器的搜索功能提取出來做成搜索引擎，同時(shí)部分場(chǎng)景使用NoSQL提高性能，

當(dāng)然以上架構(gòu)還存在部分問題，如負(fù)載均衡服務(wù)器是單點(diǎn)，因此也可以將負(fù)載均衡服務(wù)器做成集群，進(jìn)行主從的熱備，同時(shí)做一個(gè)自動(dòng)切換的解決方案。

過程中：安全性、數(shù)據(jù)分析、監(jiān)控、反作弊........
繼續(xù)發(fā)展：SOA架構(gòu)、服務(wù)化、消息隊(duì)列、任務(wù)調(diào)度、多機(jī)房........

1. 使用unique,有更多要求可以擴(kuò)展 https://d.laravel-china.org/d...
2. \Illuminate\Validation\Validator