Float是我們在設計網站前端的時候，很常用到的一個CSS屬性。我們常用它來讓DIV等標簽貼向左邊或者右邊。關于Float的用法，大家可以去看看w3school的介紹：w3school：CSS float 屬性其實Float共有4個用法，我們常用的方法是設置是下面這兩種：float:left;float:right;我們在設置不同分辨率CSS樣式的時候，可以用float的right來替換left以達到某些設計上的要求，但是我們的要求是多變的。先森在適配網站自適應的時候，就遇到了設置了左右浮動的標簽，在更小分辨率想要將其設置為居中的狀態的時候設置不成功的情況，這時先森就想讓它的浮動效果清除掉。清除左右浮動其實也很簡單，上文說了Float共有4個用法，除了常用的左右浮動，還有兩個用法分別是"none"和"inherit"。從字面意思上就可以看出它們的用法，分別是“沒有”和“繼承”。在我們想要將其浮動清除的時候，只需要設置以下屬性即可：float:none;關于Float的浮動，清除起來還是比較容易。但是關于定位的屬性position的定位，如何清除它的影響先森還是沒能琢磨的透。網上提出的有兩種解決方法，一個是overflow，另一個是clear:both，只能看哪個有用設置哪個了。網站自適應之清除標簽的float浮動

先森用了幾天的VeryCloud、騰訊云兩個云服務商的CDN，時間雖短，卻問題不斷。為了不讓自己忘記這些來之不易的經驗，先森覺得把它們寫出來，記下來。當然能幫上人就更好了。除了本篇文章，先森之前還寫了一篇總結，有興趣的也可以去看看：第一篇：VeryCloud、騰訊云CDN使用技巧總結之查看命中緩存情況下面，先森來做新一輪的總結。1.搜索引擎線路解析什么是搜索引擎線路？即專為搜索引擎單獨設置的DNS解析線路。為什么要設置搜索引擎線路？先森主要是在張戈博客接收到了這么一個理念，搜索引擎蜘蛛也許有一個DNS的解析緩存，對你網站解析的IP會保存一段時間，這個時間大概一兩天。而我們使用的CDN是讓訪客訪問就近的服務器節點，每個節點都有單獨的IP，而且這個IP還不是長時間保留的。這就相當于我們的網站經常更換服務器，這樣我們自己都會感覺不好吧，何況是蜘蛛？同時，我們的網站設置CDN后，搜索引擎蜘蛛訪問的也是節點IP，而一旦蜘蛛對這個IP進行緩存，緩存時間大于CDN的IP存在時間的時候，蜘蛛就訪問不了這個IP了。那么蜘蛛就會判定我們的網站存在問題，最終導致SEO受到傷害。大概就是這么一個觀點，詳細的內容還請大家去看看張戈博客的原文：淺析網站更換ip或使用CDN會不會影響SEO排名而解決或者說不產生上面的問題的方法，就是設置搜索引擎線路。雖然張戈已經說得很清楚了，如何設置搜索引擎線路，但還是有很多站長在問設置問題。包括先森自己，也是研究了一下，才想明白該如何設置。首先，奉勸和我之前一樣，一直使用萬網域名解析的，趕緊換換吧。下面再次簡單講講先森的經歷。萬網解析只支持百度、谷歌、必應三家的搜索引擎線路，重點是解析的還不準確。不，是非常不準確。先森用百度抓取診斷，該抓取CDN節點IP的還是抓取，設置和沒設置完全沒有什么兩樣。萬網設置搜索引擎線路后的百度抓取診斷百度抓取的IP實為騰訊云的CDN節點IP問張戈博客的張哥，張哥給我兩個解決辦法，一是換DNSPod解析，二是使用百度云加速，因為云加速有自動的搜索引擎回源。先森因為才開始使用VeryCloud不久，還想再研究研究，就選擇了使用DNSPod的方法。關于如何將域名解析從萬網轉移到DNSPod，先森也分享過方法，因為DNSPod的方法有點老舊了：將萬網/阿里云域名DNS地址修改到DNSPod如何設置搜索引擎線路？首先新增一個解析記錄，然后開始設置。主機記錄：根據需求，如果直接解析域名，填“@”；域名、二級域名都要解析，填“*”；只解析一個二級域名，填二級域名的值，如“www”。先森就只解析www的。記錄類型：選擇A記錄。線路類型：DNSPod支持百度、谷歌、必應、搜搜、搜狗、奇虎，和相當于默認搜索引擎線路的“搜索引擎”。先森是每個搜索引擎線路都單獨設置了一條A記錄。記錄值：這里就設置自己源站服務器IP，即真實IP，要小心，不要泄露。其他各項就根據自己的需求設置了。下面貼出先森的設置情況：DNSPod搜索引擎線路設置設置之后，先森立馬到百度站長工具去抓取診斷，秒秒鐘虐了萬網：抓取IP為源站IP2.詳讀“常見問題”這一點，就是讓大家去仔仔細細的將VeryCloud、騰訊云的“常見問題”看完，這樣能使我們少走很多彎路。這也是先森在問了售后很多問題之后發現的，有很多問題，都已經寫入“常見問題”中了，相信售后的心是崩潰的。其實說到底，就是多讀、多看、多想。兩個CDN服務商都有常見問題頁面，但是先森覺得VeryCloud的常見問題比較偏原理解釋，重點介紹了什么是CDN、CDN如何工作、CDN的優勢、什么是緩存命中率等等：VeryCloud常見問題其實VeryCloud的話，大家更應該點擊上圖紅框中的云分發，看更多更有針對性的解決問題方法。單頁不能忽視這一頁15個常見問題的作用，這些基礎知識能讓我們對CDN更加了解。更多詳情就希望大家自己查看了：VeryCloud云分發-使用幫助VeryCloud常見問題而騰訊云的常見問題頁面，則做的更加細致，問題更加全面，也有著很好的針對性。騰訊云對自家服務進行了介紹，其中有優勢，有原理，有功能。從基礎介紹，接入相關，日常使用，問題排查四個方面回答問題，顯得簡單明了。其中就有如何判斷用戶訪問是否命中CDN cache、接入cdn之后網站打不開，如何排查、命中率低是什么原因呢等經典問題，這些問題有很多都是現在自己搞了很久才弄明白的，沒想到這里就很清楚的寫著：騰訊云常見問題在這里，先森也把騰訊云的相關鏈接貼出來，騰訊云還有一個內容分發網絡的幫助文檔，文檔中包含以上內容，查看卻沒有以上內容方便，但先森還是一并貼出來：騰訊云CDN常見問題騰訊云內容分發網絡常見問題騰訊云內容分發網絡CDN論壇騰訊云還介紹了一個可以管理查看CDN中緩存文件軟件SVN的使用方法，但是騰訊云卻沒有使用SVN源了，讓我們使用他們的對象儲存業務COS。3.查看日志不管是VeryCloud還是騰訊云，都支持查看日志。但是他們的日志下載之后，打開顯得非常凌亂，雖然很詳細，但遠不如直接在網站上查看統計分析來的簡單明了。主要還是，關于CDN日志，他們都沒有提供什么統計分析軟件。不過先森覺得，查看日志主要也是排查問題的，很具有針對性。簡單的來說，騰訊云統計里可以看到訪問返回碼，我們可以看到產生了多少次的404，但是看不到是哪些頁面出現了404，這時候就需要查看日志了。先森問了騰訊云的售后，售后推薦使用notepad++，sublime兩款軟件。日志的內容顯得很亂，但都是每行一條，每條里面有很多數據，這些數據是按照順序來的。VeryCloud日志：例：12.243.121.90 - - [24/Mar/2015:12:42:18 +0800] "GET http://www.verycloud.cn/usr/uploads/201503/20150302100356_29670.flv  HTTP/1.1" 200 1933334 "http://portal.verycloud.cn/galileo/20150306/8ad1637dbf7cd191f1fe728fc18658d9.swf" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36" TCP_MEM_HIT 0.947 58.22.102.229字段參數客戶端真實ip12.243.121.90請求時間24/Mar/2015:12:42:18方法GETURLhttp://www.verycloud.cn/usr/uploads/201503/20150302100356_29670.flvhttpversionHTTP/1.1狀態碼200請求字節1933334Refererhttp://portal.verycloud.cn/galileo/20150306/8ad1637dbf7cd191f1fe728fc18658d9.swfUAMozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36結果TCP_MEM_HIT處理請求時間0.947節點IP58.22.102.229騰訊云日志：拿先森自己網站的日志中的一行作為例子：20160407104007 180.97.171.210 www.cnidcc.cn /qzcdnhcjszjrtxy.html 12276 120 2 200 NULL 1 "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"字段參數請求時間20160407104007訪問域名的客戶端IP180.97.171.210被訪問域名www.cnidcc.cn文件請求路徑/qzcdnhcjszjrtxy.html本次訪問字節數大小12276省份120運營商2http返回碼200referer信息NULLrequest-time(毫秒)1User-Agent"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"關于省份和運營商代碼所代表的含義，還需要我們去查看騰訊云的映射表查看地域及運營商編碼映射表注：Referer信息，保存的是訪問該網頁是從哪個頁面鏈接過來的，我們統計搜索引擎跳轉，就是用的這個信息。4.文件刷新使用CDN有一個很大的問題，就是動態數據的顯示問題。最容易涉及到的，就是文章的訪問量，以及最新評論的問題。關于訪問量，無傷大雅，只要設置緩存策略的時候緩存時間設短一些就還好。至于文章的最新評論，就有點不好了。別人在你的網站上留了言，明明通過審核了，卻還是顯示之前的頁面，最新的評論就沒有顯示出來。這時候我們再去手動的刷新緩存的話，就會比較麻煩。所以，我們就需要用到刷新緩存的API了。我們使用API，實現當頁面增加了評論的時候，刷新該頁面。具體的使用方法是將一些代碼放入WordPress主題functions.php文件中即可，代碼是張戈博客提供的，需要的小伙伴可以去看看：VeryCloud：WordPress發布/更新文章、提交/審核評論自動清理VeryCloud緩存騰訊云：WordPress發布/更新文章、提交/審核評論自動清理騰訊云CDN緩存另外，VeryCloud的API，是不對外開放的，向售后工程師申請的時候，也要保證自己網站帶寬夠大，才能申請成功。售后工程師給先森的回復是要達到20M的帶寬，這對張戈博客當然不成問題，但是對我們這些小站來說，差的太遠。雖然有小伙伴在先森交《全站CDN緩存加速之接入VeryCloud》一文中回復說，VeryCloud開放了API接口，但先森查看之后發現，實際還是需要讓你想客服索要API。總結回顧一下，本文主要介紹了如何設置搜索引擎解析線路，通過詳讀“常見問題”來少走彎路，如何查看VeryCloud的日志，日志內容的參數含義，以及如何用API接口來實現刷新緩存。現在就總結這些，如果以后還有什么好的經驗，先森還會默默的更新的。

先森用了幾天的VeryCloud、騰訊云兩個云服務商的CDN，時間雖短，卻問題不斷。發現問題→解決問題是使人進步的途徑。這來來回回的問題，雖然讓先森愁白了頭，也讓先森get到了很多技能。此文的作用，是為了不讓自己忘記這些來之不易的經驗，如果能幫到人，那就更好了。1.騰訊云關于騰訊云的命中緩存，先森一開始用騰訊云CDN就發起工單問了售后。估計先森遇到了一個騰訊云的雛，直接回復先森的沒有通過響應頭查看命中緩存的方式。先森也是醉了，他讓先森看前后對比，后面讓先森檢驗MD5：騰訊云雛鳥后來先森通過實際使用，終于發現了正確的使用方法，并且又發起工單證實了。以下是一位騰訊云老鳥的回復：“您好：如何判斷用戶訪問是否命中CDN cache查看訪問回包頭部的X-Cache-Lookup信息X-Cache-Lookup:Hit From MemCache 表示命中CDN節點的內存X-Cache-Lookup:Hit From Disktank 表示命中CDN節點的磁盤X-Cache-Lookup:Hit From Upstream 表示沒有命中CDN”簡單明了爽快。先森用的聯通，只有電信線路解析的是騰訊云。通過360的奇云測，先森發現電信線路大部分都有命中緩存。騰訊云CDN命中緩存2.VeryCloudVeryCloud是否命中緩存的查看方法，其實先森已經在網站接入VeryCloud一文中已經介紹過了，但是這里為了做一個歸納，且先森發現了新的方法，所以再次貼出。首先，查看是否緩存命中的方法還是看響應頭，有一項很顯眼的Powered-By-VeryCDN，HIT表示命中緩存，MISS表示回源，沒有命中緩存：VeryCloud命中緩存其實讓先森很不開心的，就是用奇云測還能看到一些HIT命中緩存的情況，先森本地嘗試則重來沒有命中過緩存，為這事先森找了幾次客服。今天先森遇到了認識的第四個VeryCloud售后工程師，他告訴先森，是因為每次刷新訪問的CDN節點不同導致的。我們知道，CDN是在網頁第一次被訪問的時候緩存，第二次訪問的時候訪問緩存。而每次訪問的節點不同，就導致不停的在為不同的DN節點緩存，而沒有命中緩存。并且這位工程師教了先森一項更準確的檢查方式。先森查看響應頭用的是瀏覽器的方式，這位工程師教的則是Linux命令查詢了。幸好先森虛擬機里裝了Linux，雖然是圖形界面的，但是也能用。當然，我們要讓Linux聯網，怎么聯網先森就不贅述了。使用的是wget命令，熟悉Linux的童鞋應該會常用到。這里主要是介紹給和先森一樣沒怎么接觸過Linux的站長，反正先森是感到很驚奇啦。進入Linux，右鍵“在終端打開”，進入類似windows中cmd的界面。代碼有以下兩種：wget -SO /dev/null urlwget -SO /dev/null url -ehttp_proxy=ip其中，將url改成你想要測試的鏈接，ip改為你想要測試的CDN節點IP。下面是先森用Linux的測試情況：wget -SO /dev/null urlwget -SO /dev/null url -ehttp_proxy=ip總結這樣能滿足我們對緩存設置情況進行檢查，但是要使每個CDN節點都能命中緩存，要不就內容預取，要不就只有增加自己網站的訪問量了。因為CDN畢竟是訪客第一次訪問的時候直接回源并開始緩存，第二次訪問的時候命中緩存。訪問量要是多的話，當然就更容易命中緩存了。

關于為何要接入CDN，而且是全站接入CDN，先森就不在贅述了，這些在寫接入騰訊云的時候就已經寫過了。關于VeryCloud，先森其實以前也沒聽說過，但是為了緊跟張戈博客張哥的腳步，先森也跟著做了。關于先森接入騰訊云CDN的過程，希望大家也能看看：全站CDN緩存加速之接入騰訊云用了兩天的VeryCloud，先森對它是有愛有恨。愛的是VeryCloud的售后工程師真的很好。VeryCloud雖然也有系統，但先森第一次使用的是他們的企業QQ，所以后面就一直用的企業QQ和售后交流。先森先后遇到了3個售后工程師，可能他們的售后都被先森問了個遍吧。三個售后都非常好，可能先森的問題已經要把他們逼瘋了，卻依舊能很好的應對。先森有時還問了一些不是他們VeryCloud的問題，他們也會對先森做出指導。但是，無論先森怎么設置VeryCloud的CDN，總是沒能達到預想的成果。先森的靜態文件放在七牛的，所以不需要VeryCloud的CDN緩存。開始沒有在意，先森想著VeryCloud和七牛兩個都把靜態文件緩存一邊挺好的。但后來一想，這樣會導致七牛鏡像會從CDN鏡像，而CDN鏡像會對文件進行一些壓縮，尤其是圖片，這樣會導致最終展示的圖片清晰度減小，所以最后把靜態文件緩存關了。也不知道這樣的理解對不對，但是確實也導致了第一天七牛無法回源，顯示：{"error":"get from image source failed: E502"}，而頭部的返回解析狀態碼則顯示478。各種地方尋求幫助，把顯示逼瘋了，結果還是自己好了。然后七牛的工單有反應了。。。而先森想要達到的效果，是網頁代碼，讓VeryCloud進行緩存，而靜態文件，則讓七牛緩存。然而根據先森的理解，并沒有實現。好吧，廢話了這么多，回歸主題，先森再談談VeryCloud。VeryCloudVeryCloud非常給力，每個月都是50G的免費CDN流量。而對于我們這種網站本身服務器流量每個月10G都用不完的來說，簡直多的不能再多了。反正先森用了3天，也沒用幾百兆流量。使用流量很慢怎么接入什么的，在其網站上幫助里面都寫的很清楚了，先森也就不班門弄斧了。重點是緩存設置，先森是按照自己的想法設置的，而感覺實際生效情況卻沒有跟著先森的想法走。先森的想法是，后臺不緩存，前臺的今天資源不緩存，只緩存HTML界面以及WP Super Cache的緩存目錄。所以先森是這樣設置的：VeryCloud緩存設置若有網友知道怎么設置能夠實現先森想法的配置，還請指明。先森問了售后工程師，VeryCloud的緩存策略也是有優先級的，這點在其設置中沒有明確指出。優先級別是從上到下，越上面的越優先。這兩天鼓搗CDN，讓先森新get到的技能，就是看網頁的頭信息，也就是按F12到network里面去看header中的信息。CDN緩存設置中的是否遵循源站，源站的規則，在這里就能夠看到。看頭部信息，CDN方面最重要的就是看緩存的命中情況。先森也是詢問售后工程師之后，才知道了怎么查看VeryCloud的命中情況。VeryCloud命中情況查看VeryCloud命中情況，是通過查看頭部信息中響應抱頭的'Powered-By-VeryCDN'項，如上圖紅框“Powered-By-VeryCDN:MISS from cuc-xg-1-1-c1761, MISS from utn-ho-1-1-c17a1”。先森還框住了兩個'MISS'。在這里，MISS代表著沒有命中緩存，回源。而如果命中緩存，則顯示HIT。可以看到，先森這里顯示的是MISS。而這里的兩個MISS，第一個MISS代表著從瀏覽器到CDN命中緩存失敗，第二個MISS顯示從CDN到源站服務器命中緩存失敗。先森無論刷新多少次，HTML的緩存命中都是MISS了的。但奇怪的是，VeryCloud中的統計情況又顯示HIT遠遠超過MISS：VeryCloud緩存命中統計VeryCloud管理功能讓先森用著有點沒頭腦，經過售后工程師的解釋，先森才明白，那個列表不是顯示緩存到的文件目錄，而是刷新紀錄。先森還是沒把對象存儲和CDN加速區分開，這是深受七牛影響。。。VeryCloud內容刷新先森嘗試著刷新了一波，讓先森想起了一件有點郁悶的事情：VeryCloud內容刷新-提交刷新這里的來源顯示的是來自API。張哥提醒過，VeryCloud的API沒有開放，需要的時候要直接向客服索要，先森去要的時候卻遭遇了清明節——放假，著實有點郁悶。總結對于CDN，先森是沒有怎么搞明白的，每次感覺搞明白了，卻又會被現實潑了冷水。先森是打算轉戰百度云加速了，近期會做嘗試。寫本文的期望就是希望能讓和先森一樣的小白能吃點經驗，少走一些彎路，雖然這些對大神們來說是基礎，但先森希望能給未來的大神們奠定奠定基礎。另外，解析搜索引擎線路的時候，真的不能使用萬網解析，萬網解析的非常不準確，先森將域名解析轉至了DNSPod，百度抓取診斷馬上就準確了。而且DNSPod解析線路非常豐富，幾乎囊概了所有的搜索引擎，而且還有一條名為“搜索引擎”的線路。不知道怎么轉出萬網？將萬網/阿里云域名DNS地址修改到DNSPod

近期先森為全站設置了CDN，這樣雖然可以使全國各地的訪客打開網站更快，同時也會導致百度等搜索引擎抓取網站的時候會抓取到CDN的IP地址。為了解決這個問題，先森在萬網域名解析設置了單獨的百度、谷歌、必應的解析線路。然而先森在百度抓取診斷的時候，抓取到的卻都是CDN的IP。發工單到阿里云，和售后工程師扯了半天，最后竟然說百度有問題，讓先森去找百度。然后先森問了張戈博客張哥，張哥很快回復先森說萬網的解析不準確，讓先森用百度云加速或者用DNSPod解析。很明顯，先森選擇了后者。百度云加速過段時間再用。先森一直覺得，萬網跟了阿里云后，功能很強大，但是設置卻有點繁瑣，這可能也是先森這方面的技術、意識還沒到位的原因。先森想將域名解析改到DNSPod，卻發現在萬網迷了路。看了一下DNSPod的教程，發現教程好像有點老：DNSPod萬網解析轉移教程就算是還能用，但是這里還需要多設置一個單域名控制臺授權，而這個設置，萬網為了域名安全，默認和建議我們是將其關閉的:單域名控制臺授權那么到底要怎么才能修改域名的DNS地址呢？先森也是找了一會才找到的，不在萬網域名控制臺的域名解析里面，而是在基本管理里面：萬網域名控制臺-基本管理當然，先森這里是已經修改好了的。如果是和先森一樣，是打開了[域名安全鎖]的，還需要去關閉之后才能修改，可以修改之后再將其打開。

成都航院計算機工程系教過先森網頁樣式代碼CSS，但是正如先森對大學的領悟“大學是一個真正讓你體會什么叫做‘師傅領進門 修行靠個人’的地方”一樣，老師教的畢竟是基礎，不可能面面俱到。實踐出真理，先森漸漸也摸索出了一些對于網站上圖片的寬width和高height的一些心得。先森的網站上用的是百度UEditor編輯器，先森一直覺得這個編輯器很好用，但是還是有些小毛病，需要我們自行改造插件。其中一個問題，就是UEditor在上傳圖片的時候，會設置兩個圖片的寬高屬性：<img width="***" height="***" style=="width=***px;height=***px;" />這樣看著是沒有什么問題的，但實際使用起來卻產生了在移動端圖片無法自適應的問題：高度操持不變，寬度自適應。這就導致了圖片拉伸。先森當初也是到處尋求幫助，最終自己檢查出來的。圖片被拉伸當然，這最終被先森解決了。關于更多百度UEditor編輯器的內容，先森也為大家分享了：百度UEditor編輯器插件1.4.3.1 For WordPress解決使用百度UEditor編輯器后移動端圖片被拉伸問題解決百度UEditor編輯器上傳的圖片無法被七牛CDN自動緩存問題WordPress百度UEditor編輯器自動添加七牛云儲存裁剪代碼好了，上面說多了。其實本文中主要說的不是后面的style中的寬高，而是前面的img標簽中的寬高。這個寬高之前先森是沒有怎么注意的，認為先森已經在CSS中設置了圖片的寬高，這個寬高就沒必要設置了。相信很多站長和先森的想法是一樣的。但是先森看了露兜的一篇文章之后改變了這個看法。童鞋們可以先去看看w3school中對img標簽的說明：HTML <img> 標簽的 height 和 width 屬性w3school詳細介紹了img標簽中width和height兩個屬性的重要性。先森看中的其實是露兜文章中一個評論的解釋。關于這篇文章，大家也可以去看看，露兜大大也對這條評論做了著重推薦：WordPress 自動去除img的width和height屬性而先森看中的評論內容則如下，是一個ID為“于江水”的哥們寫的：“這樣做從前端的角度來說是不合理的。img 的 alt 屬性是必須的，width 和 height 是推薦的。因為 img 在網頁的加載是要比 div 這些結構慢的，所以往往是結構和文字先加載了，再加載的圖片。這時候，由于瀏覽器預先不知道圖片的尺寸大小，所以無法渲染圖片在網頁中的位置和尺寸。等圖片加載進來之后，再進行渲染，這時候就產生重繪（就是瀏覽器重新計算相關元素的位置，具體表現就是圖片出現了，圖片下面的文字跑到下面了，淘寶的商品介紹頁面，這里非常明顯。）而帶有 width 和 height 的 img，瀏覽器會計算出來，留空，然后等待圖片加載，避免頁面重繪，提高前端性能和用戶體驗，這里在知乎上多圖的答案可以看出來。那么回到露兜大大在乎的響應式的圖片處理。這里應該對 img 設置 max-width: 100%; height: auto; 這兩條屬性，才可以保證成比例拉伸。”總結起來也就是設置了width和height兩個屬性后，瀏覽器會給沒加載出來的圖片留出應有的位置。初看這個觀點的時候，先森雖然知道了，但也沒有重視。所以，也就在網站改版的時候沒給圖片加width和height兩個屬性。先森在改版后，又加入了CDN，在GTmetrix測試網站的時候，結果第一條優化建議就是給圖片指定尺寸（點擊放大）：GTmetrix測評優化而且先森這一點的得分是0分，是在有點郁悶，看來圖片width和height兩個屬性真的很重要。所以建議大家上該設置的還是設置上。至于設置的方法，可以參考上面給露兜大大留評論的那位仁兄的方法：max-width: 100%; height: auto;

先森的網站在安卓版UC瀏覽器上出了BUG，這次先森有點摸不著頭腦，因為只有安卓版才存在這個問題，所以先森想要直接從電腦調試手機，就像電腦上F12審查元素調試網頁一樣。昨天發布了一篇Adobe Edge Inspect CC的折騰經過，一把辛酸結果還沒成功。最后還是放棄了。先森在百度Adobe Edge Inspect CC教程的時候，也看到過另一種安卓調試方式，就是利用谷歌的Chrome瀏覽器遠程調試(Remote Debugging)。其實另外還有一個叫做Weinre的，但是先森在其官網上找來找去，感覺和Remote Debugging是差不多的。然而Chrome瀏覽器的遠程調試需要用數據線連接安卓手機，并且手機要開啟開發者模式。開始開發者模式簡單，但是先森折騰了一下午，也沒能把三星、華為的手機驅動裝好，電腦始終不能連接手機。后來用能夠連接手機的電腦嘗試了，結果谷歌Chrome瀏覽器遠程調試界面還是沒有顯示出手機（Chrome瀏覽器地址欄輸入chrome://inspect 或者about:inspect）。沒辦法，放棄。到了晚上，先森在放棄之后突然想起，Chrome瀏覽器電腦上有個開發者模式，UC瀏覽器有沒有呢？結果一百度，就找到了一個讓先森驚喜的搜索結果，也就是本文的標題，UC瀏覽器開發版。大家可以去看看，越看越驚喜哦！UC+開放平臺：UC瀏覽器開發者版先看最終的效果圖，先森將瀏覽器的調試界面和手機被調試的界面拼在了一起，這樣看起來效果更直觀（點擊后按F鍵看最大化/點擊倒數第二個按鈕）：UC瀏覽器調試界面配置調試模式其實關于如何配置，UC+開放平臺已經寫得很清楚了，只是先森在設置的時候還是走了一截彎路，所以先森還是把自己的調試過程寫出來。1.準備工作手機端下載UC瀏覽器開發者版，電腦端安裝chrome瀏覽器（先森嘗試了下UC瀏覽器電腦版，好像不行）。2.連接手機與PC有兩種連接方式。一種是WIFI連接，手機與電腦同一個網段下即可。另一種是USB連接，這又是像上面說的一樣，需要手機進入開發者模式，電腦數據線連接手機，而且USB連接模式需要搭建AndroidSDK開發環境或安裝adb工具。關于怎么USB連接，UC有詳細介紹，先森不在累述，而且先森使用的是WIFI連接。WiFi連接非常方便，先森推薦使用這種方法。3.開始調試WIFI連接的話，直接在chrome中輸入：手機IP+:9998關于手機的IP查看，一般在設置->關于設備->狀態，可以找到。USB方式的先森就不多說了。輸入訪問后，手機上UC瀏覽器開發者版會彈出對話框，先森用的是三星S3，情況如下圖：UC瀏覽器開發者版彈出對話框這里點擊確定就行了。然后chrome瀏覽器會顯示出UC瀏覽器中打開的網頁索引界面:chrome瀏覽器索引界面顯示這時，點擊任一需要調試的頁面即可進行調試。調試的界面和審查元素的樣式一樣，操作起來感到非常熟悉：chrome調試頁面當UC瀏覽器開發者版的某個頁面被遠端瀏覽器調試時，系統通知欄會顯示扳手圖標，提示UC瀏覽器-調試模式開啟，表明當前手機頁面處于調試狀態。先森想說，震動模式的三星，進入調試模式的震動時間還真長，長！折騰總結這次折騰網頁手機調試，Adobe Edge Inspect CC浪費了先森上午半天時間，USB手機連接電腦浪費了先森下午時間，UC瀏覽器開發者版先森沒看懂，去折騰安裝adb工具（實際上WIFI模式根本用不著）折騰了一晚上。浪費了一整天，然而并沒有成效。結論就是折騰之中無時間。另外，實現WiFi調試是先森第二天早上花了一分鐘成功的。。。

先森完成手機自適應的大框架之后，開始處理各種BUG，其中UC瀏覽器安卓版中的BUG尤為突出。BUG表現為首頁輪播幻燈片圖片放大，互相遮蓋。而且，這個問題僅僅出現在安卓手機中的UC瀏覽器里，表現情況如下圖：安卓UC瀏覽器BUG出現了這種問題，讓先森感到很郁悶。不論是安卓自帶瀏覽器，還是iPhone各種瀏覽器，都不會出現這種問題，只有安卓UC瀏覽器出問題。既然出現了圖片互相遮蓋的問題，肯定是CSS沒有寫好。這時候先森想起逛知更鳥博客的時候，鳥叔的推薦15款響應式Web設計測試工具文章中的Adobe Edge Inspect CC：Adobe Edge Inspect CC如果對鳥叔的這篇文章感興趣的可以去看看：知更鳥：推薦15款響應式Web設計測試工具折騰過程Adobe Edge Inspect CC的推薦語寫的很好：Adobe Edge可以讓你在設備上預覽和檢查響應式網站。先森起初以為這只是個瀏覽器插件，想著很好用，剛好拿來調試UC瀏覽器上出現的問題，就在谷歌插件里面搜索安裝了。然而，并沒有這么簡單。當然，要上谷歌，需要科學上網。還不會的童鞋可以看這里：科學上網：分享兩款免費好用的帆墻軟件電腦和手機都安裝好這個插件之后，先森無論如何都無法照著網上教程一樣連接，chrome瀏覽器中Adobe Edge插件一直只顯示一句話：“Please start the Adobe Edge Inspect Application...Get Edge Inspect.”（請啟動的Adobe邊緣檢查應用程序...找邊檢查。）請啟動的Adobe邊緣檢查應用程序...找邊檢查而點擊鏈接，就只能到Adobe官網中介紹Adobe Edge Inspect CC的網頁。通過觀察網絡教程的截圖先森發現，先森Adobe Edge插件和別人教程里的不一樣，首先和chrome商店里插件下載的截圖中就不一樣。chrome商店中的Adobe Edge插件下載頁的Adobe Edge在瀏覽器中的圖標是橙色的，而先森的則是灰色的，明顯的未啟動的樣式。后來知道了，還有一個Adobe Edge Inspect CC的軟件，好吧，先森下載安裝。結果安裝好之后軟件界面都打不開，直接跳個提示框："Your username and password are incorrect or your account does not have access to Edge Inspect CC"（您的用戶名和密碼不正確或您的帳戶沒有訪問到邊緣檢查CC）。好吧，先森還沒有崩潰。接著百度谷歌之后了解到，需要安裝登錄一個CreativeCloudSet-Up.exe，Adobe的一個什么創意云套裝，專門下載、安裝和更新Adobe CC系列軟件的。登錄需要Adobe ID，沒有的話，還需要注冊。放心，注冊免費，不會對你造成什么不良影響。好像注冊的時候需要科學上網。如果你看到上面就跑出去注冊ID了的話，再看這里先森會告訴你，還是沒有什么卵用。登錄之后，第一次打開Adobe Edge Inspect CC的時候，OK，成功打開，沒有跳提示框。打開手機Adobe Edge Inspect CC插件，終于搜到電腦了。但是！但是打開瀏覽器還是灰色狀態！也就是還是沒有啟動。好吧，先森認為重啟一次應該可以湊效。重啟ING...登錄創意云，OK，沒問題。打開Adobe Edge Inspect CC軟件，出問題了。提示框又出來了。這下先森沒轍了。折騰總結：1.浪費了半天時間；2.安卓UC瀏覽器中的BUG并沒有修復；3.先森感到很不爽。折騰第一記·完

先森在完成網站自適應的過程中，遇到了很多大大小小的問題，其中一個問題就是橫屏字體變大的問題。這個問題一碰到感覺很麻煩，其實解決方法卻很簡單。網頁自適應解決iPhone手機橫屏字體變大問題網上搜索結果中有很多答案，但是經過先森實踐后，最終覺得有用的是在style.css中添加以下代碼：/***修復iPhone橫屏后字體變大問題**//www.cnidcc.cn/wyzshjj_iphone_sjhpztbdwt.html*/@media screen and (max-device-width: 320px){body{-webkit-text-size-adjust:100%}}@media screen and (max-device-width: 480px){body{-webkit-text-size-adjust:100%}}@media only screen and (-webkit-min-device-pixel-ratio: 2){body{-webkit-text-size-adjust:100%}}@media only screen and (min-device-width: 768px) and (max-device-width: 1024px){body{-webkit-text-size-adjust:100%}}其中最重要的代碼這個屬性：-webkit-text-size-adjust“-webkit-text-size-adjust”是CSS3中的一個屬性。這個屬性，從字面上來看，就是“WebKit的文字大小調整”的意思。什么是WebKit呢？這是一種開源的瀏覽器引擎，而蘋果的safari瀏覽器用的就是這種內核。其實chrome、Android的也是WebKit內核，但是先森調試的時候用的是iPhone，所以這里就只說iPhone了，而且好像只有iPhone容易遇到這個問題。在WebKit內核的瀏覽器中規定，當在css中定義的中文font-size小于12px的時候,瀏覽器仍然使用12px。字體也會隨著網頁的變大而變大，這也是當你手機橫屏時，字體變大的原因。而控制這個功能的，就是CSS 中的 -webkit-text-size-adjust。text-size-adjust 設為 none 或者 100% 則關閉字體大小自動調整功能。大家可以看出，先森在上面提出的代碼中，用的是100%而不是none，這是為什么呢？先森看了一篇博文，當時沒有收藏，所以現在也不知道是哪看到的了。博主提出，添加none會有問題，所以建議設置為100%。當時博主沒有說是什么問題，我們想想也就明白了。如果設置none的話，隨著網頁變大，你的文字還是不會變化，這就導致用戶體驗不好了。所以也有很多回答建議不要講該屬性設置為全局屬性。先森最初找到的代碼也是設置的none，但是看了這篇文章后先森將其改為100%。其實用none也沒有問題，因為上面的四行代碼是判斷瀏覽器寬度后生效的。這一點就見仁見智了，根據大家的實際情況來使用。

成航先森，成都航院計算機系一個學生的個人網站。磕磕碰碰，從去年6月19日建站以來，終于本站又迎來了一個大的改版。本次改版主要針對的是網站的自適應，即根據訪問者屏幕的寬度，調整網頁布局。以前先森采用的是PC端使用先森自己制作的主題，手機端使用"WordPress Mobile Themes"插件，將移動端的訪問設置為知言Tinection主題。這個主題提供收費和免費兩個版本，小站當然用的免費版本。本來用著還好，但是先森始終覺得手機端用這個主題，顯得非常的不流暢，近期更是產生了圖片不顯示的問題。先森真好有空，索性就開始網站自適應制作了。曾經在貼吧里就有站長提醒先森，手機端上Tinection主題不怎么好用，現在看來確實不怎么合適。經過幾天的鼓搗，終于將這個自適應做出來了。如果有站長朋友訪問可以看出，網站有點知更鳥 鳥叔的Begin主題的痕跡。Begin主題是收費主題，售價299元。收費主題的前端代碼當然寫的夠好，先森也只能借鑒前輩了。來看看本站在各終端的樣式：主題各終端樣式上圖可以看出，此次本站對各終端的顯示還是比較適配的。先森通過百度站長工具的移動適配中的移動友好度檢測了一下，這次終于不是以往的各種優化建議了：百度移動友好度雖然現在網站的各方面還有一點小問題，但是先森會竭盡所能的修復的。如果網友們發現了什么BUG，希望能在下面的評論區提醒先森（拜托拜托~~）。通過這次的實戰，先森學到了很多前端設計方面的技能，尤其是CSS和JS。CSS中規定元素定位類型的position 屬性，決定浮動的float屬性，清除浮動用的clear屬性等等，這些先森會慢慢的整理分享出來。為了緬懷過去，先森也將網站的改版前的首頁全圖貼出來：改版前的成航先森本文開頭也寫了，本站終于“又”迎來了一個大的改版。之所以說“又”，是因為本站之前不叫“成航先森”，而是“成都航院計算機工程系”。而改名的原因，就是與官網產生了沖突。曾今先森改版的時候也很糾結，所以發文一篇：糾結，建站“成航先森”這個名字，是先森征求了很多同學的意見，很多朋友幫忙想了很多很多的名字，最終選定了這個名字，并一路走到現在。真的很感謝先森的這些朋友們。先森有些文章的開頭，帶上了“【先森有友】”，這些都是朋友們的日志，或者讓先森分享的技能。兩次改版，一次是被動的，糾結的；一次是主動的，高興的。雖然不知道本站能走多遠，但先森希望能盡力的走下去。