鍍金池/ 問答/ PHP問答
咕嚕嚕 回答

類屬性默認(rèn)值只能用常量。
你可以在構(gòu)造函數(shù)中設(shè)置$uid。
但注意覆蓋父類構(gòu)造函數(shù)的問題。

空痕 回答

我試了下，發(fā)現(xiàn)結(jié)果都是一樣的??？！就是上面test.php文件中的結(jié)果

夕顏 回答

gulp 根據(jù)sass 配置文件 也就是 顏色全局變量， 打包出三套皮膚，線上代碼動態(tài)切換link src

笨小蛋 回答

首先 點擊公眾號自定義菜單 直接調(diào)起支付寶app 或是其他任何app 應(yīng)該是不行的，微信開發(fā)者平臺并未提供相應(yīng)功能，至少目前沒有。

你可以配置點擊一個按鈕時 打開一個h5頁面，這個頁面的鏈接是你可控的，因此可以打開一個你的網(wǎng)站的頁面。

在正常的瀏覽器中，前端頁面可以調(diào)用一種被稱為scheme的技術(shù)調(diào)起任意app，一般是 xxx://開頭的一個url跳轉(zhuǎn)，xxx是你app定義的namespace，支付寶也不例外。

但是微信目前屏蔽了android端任何scheme調(diào)起，ios端universal link以前可以 現(xiàn)在也被屏蔽了。因此在微信內(nèi)H5也無法直接調(diào)起app。瀏覽器里可以，因此可以出個彈層引導(dǎo)用戶去瀏覽器里打開此頁面，再跳轉(zhuǎn)支付寶。

在微信內(nèi)，你唯一能做的是調(diào)起應(yīng)用寶頁面，讓應(yīng)用寶打開app，所以這也是一條路。

更多細(xì)節(jié) 具體在下面留言吧，看你具體想怎么做。

疚幼 回答

User::join('abc','abc.id','=','users.id')->join('a','a.id','=','abc.id')->get();
用model大概就是這樣

掛念你 回答

1樓提供的方法確實是一種解決方案。適合不同控制器中重復(fù)代碼是一個功能性的內(nèi)容，比如從第一行執(zhí)行到共同部分最后一行只想得到一個結(jié)果的場景，如果不是功能性的內(nèi)容，重復(fù)部分代碼執(zhí)行過程中的數(shù)據(jù)都需要用到，那么用1樓的方法需要返回重復(fù)部分代碼執(zhí)行過程中的所有數(shù)據(jù)。不知道這樣說理解不。

另外一個方法是TP本身就有前置加載，重復(fù)部分的內(nèi)容也可以通過前置加載的方法去用。

第三種方法控制器繼承。

反正這種問題解決方法不一而足，根據(jù)自己習(xí)慣去做就好。

懶洋洋 回答

W3school
百度 PHP crypt就能查到了= =

哚蕾咪 回答

之前也做過類似的功能，我的思路大概是這樣的：

  1. 添加圖片的時候，把添加的圖片路徑（圖片信息參數(shù)等）存儲在input的name為already_photo[]的隱藏域中
  2. 修改的時候，把已經(jīng)存在的圖片路徑取出來，放置在這個隱藏域中，然后在修改的時候，替換（添加）了新的圖片也放在隱藏域中
  3. 提交整個表單的時候，用array_diff這個函數(shù)作對比，與前端文本域和數(shù)據(jù)庫的圖片數(shù)據(jù)作對比。要對比兩次，需要找到添加的和刪除的文件，該刪除的刪除掉數(shù)據(jù)庫信息，并刪除資源文件，該添加的就添加

這樣的好處是，你在添加的時候，就算替換了多次，也能得到不需要的文件信息，在提交表單的時候，通過對比，可以刪除對應(yīng)的資源文件，減少服務(wù)器上的多余資源。

做不到 回答

你就把后面文本框的值傳到后臺，后臺做處理然后返回數(shù)據(jù)啊，這種get post都行

毀與悔 回答

當(dāng)message出現(xiàn)時，你用f12查看這個message被什么選擇器控制的，然后你就把這個選擇器的樣式重寫就可以了

拮據(jù) 回答

內(nèi)部實現(xiàn)的機制而已,如果靜態(tài)調(diào)用了非靜態(tài)的方法,在內(nèi)部會觸__callStatic 魔術(shù)方法, 該函數(shù)內(nèi)會自動實例化的,,5.1的你可以看看門面(Facade); 機制應(yīng)該是一樣的!

心癌 回答

先定義動作序列，然后用一個函數(shù)來執(zhí)行動作序列

var actions = [{
    type: 1,
    msg: '你好'
  },
  {
    type: 2,
    msg: '我是老師Tom'
  },
  {
    type: 3,
    msg: '你是誰'
  },
  {
    type: 4,
    msg: '獲取數(shù)據(jù)'
  },
  {
    type: 5,
    msg: '歡迎你',
    value: true,
    conditions: [{
      type: 3,
      msg: '你上幾年級了'
    }, {
      type: 6,
      msg: '執(zhí)行動作'
    }]
  }
]

function doAction(action) {
  if (!action) {
    return
  }
  console.log(action.msg)
  if (action.type === 1) {

  } else if (action.type === 5) {
    if (action.value) {
      doAction(action.conditions[0])
    } else {
      doAction(action.conditions[1])
    }
  }
}

actions.forEach(doAction)
清夢 回答

最簡單的方式，就是Node.js跟PHP之間通過HTTP請求的方式來實現(xiàn)。

從樓主的問題，看不出來PHP、Node.js誰比較“后”的那一端。假設(shè)Node.js是更后的那一端，那么

  1. Node.js：對外提供HTTP接口（常見）
  2. PHP：請求HTTP接口。（具體怎么請求，谷歌或百度）
離魂曲 回答

salt只是用來防止 字典攻擊

解夏 回答

//實現(xiàn)斐波拉契數(shù)列

function flist($limit){
    $pre1 = 1;
    $pre2 = 1;
    for ($i=0; $i <$limit ; $i++) {
        if($i<2){
            yield 1;
            continue;
        }
        $now = $pre2+$pre1;
        $pre2 = $pre1;
        $pre1 = $now;
        yield $now;
    }
}

$flist = flist(10);
foreach ($flist as $key => $value)
{
    echo $value . "\n";
}
做不到 回答

這不是Python，是js吧==

陌顏 回答

4000次的循環(huán)本身并不大，如果循環(huán)里僅僅是對內(nèi)存的操作其實很快就應(yīng)該完成，但是你在循環(huán)里做了很多次數(shù)據(jù)庫操作，這應(yīng)該就是造成性能問題的根本原因。盡管每條sql執(zhí)行都很快，但是你忽略了每次執(zhí)行所帶來的網(wǎng)絡(luò)io開銷時間。我才想4000次的循環(huán)里如此多的數(shù)據(jù)庫操作足以是你的腳本超時了，當(dāng)你所提到超時時，我認(rèn)為你的php運行在fast cgi模式下。那么你有兩種方法來解決
1，將sql操作合并，一次或幾次在循環(huán)之外一口氣得到所有的數(shù)據(jù)，再在循環(huán)中進(jìn)行分門別類。我相信這樣做會立竿見影的提升效率。
2， 如果這個操作不是及時性的，那么可以嘗試放在cli模式下運行，你不用修改代碼，盡管效率同樣低，但cli模式下腳本不會超時。

另外如果你所獲得到數(shù)據(jù)總量很大，那么還要考慮php本身為腳本所分配的最大可用內(nèi)存，如果這個值低于你獲取的數(shù)據(jù)所需要的內(nèi)存，那么即便在cli模式腳本還是得崩。這個配置好像是在php.ini里一個叫max_memory_size定義的，名字可能不準(zhǔn)確，我記不太清了

下墜 回答

php中變量是分配在執(zhí)行棧的尾部,執(zhí)行棧zend_execute_data,實際是一塊堆內(nèi)存,是個變長結(jié)構(gòu)體,由zval來存儲變量的值,變量名是存儲在symbol_table中,在unset時,并沒有進(jìn)行出棧操作,而是將變量名稱從全局符號表(函數(shù)中則為函數(shù)執(zhí)行棧的符號表)中刪除,并且將存儲其值的zval置為IS_UNDEF,函數(shù)中的臨時變量的內(nèi)存會在函數(shù)執(zhí)行結(jié)束時進(jìn)行釋放,全局變量則在整個程序執(zhí)行結(jié)束后進(jìn)行釋放

笨尐豬 回答

你要知道TCP是流式協(xié)議，沒有消息邊界的，UDP是有消息邊界的，所以你發(fā)送端的數(shù)據(jù)，到接收端這邊，可能需要一次，或者兩次，或者一次把兩次發(fā)送的數(shù)據(jù)都接收了
610439-20160528150523303-1600111497.png
你可以想象你是在接收水流，所以你是不知道它那里結(jié)束的
可以搜索TCP粘包問題，一般解決方案有：

  • 發(fā)送定長包。如果每個消息的大小都是一樣的，那么在接收對等方只要累計接收數(shù)據(jù)，直到數(shù)據(jù)等于一個定長的數(shù)值就將它作為一個消息。
  • 包尾加上rn標(biāo)記。FTP協(xié)議正是這么做的。但問題在于如果數(shù)據(jù)正文中也含有rn，則會誤判為消息的邊界。
  • 包頭加上包體長度。包頭是定長的4個字節(jié)，說明了包體的長度。接收對等方先接收包體長度，依據(jù)包體長度來接收包體。
  • 使用更加復(fù)雜的應(yīng)用層協(xié)議。
首頁 上一頁 206 207 208 209 210 211 212 213 214 下一頁 尾頁