在线观看不卡亚洲电影_亚洲妓女99综合网_91青青青亚洲娱乐在线观看_日韩无码高清综合久久

inline-block:是使元素以塊級元素的形式呈現(xiàn)在行內(nèi),你的寬度分配雖然剛好把100%分完，但是div之間有“幽靈空白點”,在outer中，添加font-size:0就可以了， 子div可以重新設置font-size:12px;

我在界面 (WEB)上，只在 全部歌單 上看到 分類 啊，不知道你說的是什么分類信息。

通過你買服務器的控制臺登錄 把你的ssh的配置文件貼出來，就可以發(fā)現(xiàn)問題了

ORM框架是通過你調(diào)用的方法來決定怎么看待 null (作為文本就加引號，作為關鍵字就不加引號)。

看你拼接出來的 sql 語句，應該是直接 for 循環(huán)遍歷出來的，要么在循環(huán)中加判斷，遇到aliasName時，前面的key(或者其他什么，我看不出來你們這里是用什么東西來表示這個對應關系的)不加引號；要么在拿到這個
sql 語句后，手動 string.replace('null as aliasName', 'null as aliasName') 來替換掉。

apache的部署方式，我沒有使用過。我一般是是用nginx+uwsgi來部署flask的。

uwsgi --uid os373 --gid os373 --ini /var/www/pybolg/pyblog_uwsgi.ini

上面的代碼是使用uwsgi來部署我的flask程序的。執(zhí)行成功之后的log日志是這樣的。

所以，我個人認為，你用uwsgi執(zhí)行了flask項目之后，項目的相關內(nèi)容已經(jīng)加載到了內(nèi)存。所以，不會每次url請求都重新執(zhí)行app.py。但是，但是.....

每個網(wǎng)頁瀏覽器要瀏覽url的時候，都要重新執(zhí)行一下 view 視圖函數(shù)里的內(nèi)容。

用copy.deepcopy吧。

    Parameters
            ----------
    deep : boolean or string, default True
        Make a deep copy, including a copy of the data and the indices.
        With ``deep=False`` neither the indices or the data are copied.

        Note that when ``deep=True`` data is copied, actual python objects
        will not be copied recursively, only the reference to the object.
        This is in contrast to ``copy.deepcopy`` in the Standard Library,
        which recursively copies object data.

已經(jīng)解決，是由于開發(fā)工具的debug模式有影響。

1：逃逸分析JDK1.6及以后版本默認開啟；

2：可以自定義一個循環(huán)創(chuàng)建對象的方法，不設置任何參數(shù)run啟動是debug啟動循環(huán)方法耗時的10倍左右；

我也不太清楚為什么會出現(xiàn)這種情況，猜測java逃逸分析在debug模式是禁用的，有知情人可以講解下，謝謝。

初步判斷，可能是你默認瀏覽器被竄改了，檢查下默認瀏覽器設置是哪個，或者重新設置下默認瀏覽器。

undefined是console.log的返回值，你可以試著覆蓋console.log來改變默認輸出：

let tmp = console.log.bind(console)
console.log = function() {tmp(...arguments); return 1}
console.log(3)

router.beforeEach 運行在vue路由切換的時候
Vue.http.interceptors 運行在你http請求的時候
兩個八桿子也打不著啊

你可以用document.referrer來獲取上一個URL的地址，但是有以下情況不能獲取(常見情況)：
1、直接在瀏覽器地址欄中輸入地址；
2、直接新窗口打開一個頁面；

1、使用case when then 的方式進行判斷

SELECT p.id,u.username,,p.create_time,case when p.parent_id != 0 then COUNT(p.parent_id) else 0 end AS parent_num,
            case when o.style != 1 then 0 else COUNT(o.style) end AS style_num,
    p.likes,p.reward,p.end
    FROM p
    LEFT JOIN u ON p.user_id = u.id
            LEFT JOIN o ON p.id=o.post_id
            <where>
    p.status=#{status}
    <if test="keyword != null and keyword != ''">
        AND (p.id LIKE CONCAT('%', #{keyword,jdbcType=VARCHAR}, '%') OR u.username LIKE
        CONCAT('%',#{keyword,jdbcType=VARCHAR}, '%'))
    </if>
</where>
GROUP BY p.id
<choose>
    <when test="sortField != null and sortField != '' and sortField == 'parentId' ">
        order by COUNT(p.parent_id)
    </when>
    <when test="sortField != null and sortField != '' and sortField == 'likes' ">
        order by p.likes
    </when>
    <when test="sortField != null and sortField != '' and sortField == 'style' ">
        order by COUNT(o.style)
    </when>
    <when test="sortField != null and sortField != '' and sortField == 'reward' ">
        order by p.reward
    </when>
    <otherwise>
        order by p.create_time
    </otherwise>
</choose>
<choose>
    <when test="sortType != null and sortType != '' and sortType == 'asc' ">
        ASC
    </when>
    <otherwise>
        DESC
    </otherwise>
</choose>
LIMIT #{start},#{size}

其中有一個現(xiàn)象就是開發(fā)后臺在監(jiān)控微信公眾號獲取發(fā)送的事件的時候會出現(xiàn)一定延遲，即在微信響應方面有時候會有一定延遲，就是沒有及時響應用戶操作發(fā)送的事件消息，因為用戶在點擊公眾號的時候，會給微信發(fā)送event事件消息，表示用戶點擊了觸發(fā)了某中交互，微信在接受到用戶這個操作，后會發(fā)送到公眾號的對應的后臺，這個過程如果能及時響應，表示頁面加載出來就是正常的，但有時就會出現(xiàn)問題。

用戶再點擊菜單的時候會首先調(diào)取微信授權的接口，對該用戶進行授權操作，這里偶爾出現(xiàn)的白板，需要過一段時間才能夠正常，可能就是在處理授權方式上沒能及時響應，或者授權失敗，即接口中請求報錯，導致白板，可怪哉，有些手機絕對不會出現(xiàn)白板的情況，每次都能正確加載，就iphone出現(xiàn)的概率較高。且出現(xiàn)在頁面文件更新，上傳服務器之后，一段時間內(nèi)白板概率出現(xiàn)達80% 以上。

由此發(fā)現(xiàn)，可能原因有兩點：
1.微信在同一時間對同一個同一個用戶的相應，可能會發(fā)生延遲現(xiàn)象，不能正確響應用戶的操作請求，即點擊菜單延遲掉，或被后臺請求覆蓋掉，將授權失敗
2.在文件更新上傳服務氣候過后，造成微信token的變更，由此微信會在進行授權的時候，會導致授權失敗，無法調(diào)到指定的頁面導致，無法加載任何東西，（官網(wǎng)文檔沒有查閱到關于授權失敗的消息怎么處理的？，再次也無法正確調(diào)試定位問題），可要是token造成的程序問題，又怎么了接受有些手機死活不會出現(xiàn)白板問題。。。

說了這么多，只是問題的原因猜測分析，但還是沒有定位到問題的根本。主要困難在于，
1.手機型號不同，弄不清楚是什么原因造成了不同情況
2.微信授權定位調(diào)試過于困難，手機端和微信開發(fā)調(diào)試工具差距太大，非常不利于調(diào)試。。

可以用ajax去請求，如果是get方式的，記得加一個隨機數(shù)，不然有可能是緩存

= 兩邊不要加空格，這和 shell 的變量定義是一樣的

與其這樣，不如把自增的ID，改成自定義的ID。比如可以用 redis 的inc生成自增ID。

        Integer[][] arr = {
                {1, 2, 3},
                {2, 3, 4}
        };
        Arrays.sort(arr, new Comparator<Integer[]>( ) {
            @Override
            public int compare (Integer[] o1, Integer[] o2) {
                // 返回0表示相同，正數(shù)表示 o1 大，負數(shù)表示 o2大
                return 0;
            }
        });

不尷尬啊,在Koa2要順序執(zhí)行就是需要把回調(diào)方式的函數(shù)用Promise封裝的.
_
或許你在Promise中把結果reslove出來再處理會好些。
我是這樣處理的：

function evalSimpleSql(sqlStr) {
  return new Promise((resolve, reject) => {
    pool.query(sqlStr, function (error, results) {
      if (error) reject(error);
      else {
        resolve(results);
      }
    });
  });
}

簡單的sql語句就傳入evalSimpleSql執(zhí)行..
一些回調(diào)形式改寫成Promise形式的包，本質(zhì)也是這樣

能不能在內(nèi)存中格式化一樣，使用moment之類的工具

去掉Keep this code private那個勾......