現(xiàn)在這個社會最害怕的是什么，無非是紙上談兵這樣的人，你對問題的見解，你對事情的看法都有很多獨到的解釋，但是真正地讓你帶一個項目，寫一行代碼的時候，短板就開始暴露，所以對于這樣的情況一定要避免。以下內(nèi)容就是關于HTML的用法介紹，希望對大家的基礎提升有所幫助。

首先是最常用的<view>標簽與<text>標簽

<view>標簽也就是盒子模型，在它的里面可以放其他所有標簽，<text>標簽里面可以寫文字，但是我們也可以直接在<view>標簽里面寫文字。

<view>標簽是單獨占一行，但是<text>標簽卻在一行中有兩個。

這里就不得不提到一個知識點：行內(nèi)元素與塊級元素。首先，HTML的排版是從上而下進行的，塊級元素：不管它的內(nèi)容有沒有達到一整行，它都是會占據(jù)一整行，行內(nèi)元素：不會單獨占一行，只會占自己應占的長度，可以在一行中共存。

塊級元素：div，p，form，ul，li，ol，dl，form，table

行內(nèi)元素：span，strong，em，br，img，input，label，select，textarea

<image>標簽

也就是圖片，我們需要在標簽中寫上src，后面跟上它的地址，地址可以是本地地址，也可以是網(wǎng)絡地址，網(wǎng)絡地址寫法如下圖：

而本地地址就涉及到一個知識點了：相對路徑與絕對路徑。相對路徑：以自己本身A文件為參照物，相對而言B文件所在的路徑。可能大家暫時沒懂啥意思，我們接著慢慢看，../兩個點加一個斜杠，代表著返回上一層（相當于父母），./一個點加上一個斜杠代表同一層（相當于兄弟姐妹），這樣大家就好理解多了吧~

這里我在images文件夾中添加了一個圖片，但是我此時正在寫代碼的文件是demo.wxml，我要引入它，就是要返回到上一級的demo文件夾，然后返回到上一級的pages文件夾，找到同一級的images文件夾下的tupian1.png，那么我就應該src="../.././images/tupian1.png"。

而絕對路徑就更好寫了，直接用一個/表示絕對路徑，我們直接src="/images/tupian1.png"就可以啦~

input標簽

輸入框，可以看到代碼中的input標簽中間并沒有寫任何文字，但是我們可以在左邊隨意輸入，我們大家平時使用的登錄賬號，輸入文字都是用這個實現(xiàn)的~

了解著HTML用法，提升自己的能力，是最好的成長。

先強調(diào)一下，產(chǎn)品經(jīng)理需要掌握一些技術點這事不是必備項，但卻是大大的加分項，從我目前的經(jīng)驗來看，不懂技術的產(chǎn)品經(jīng)理很難做產(chǎn)品，但可能會有一些天馬行空的想法，只不過大多數(shù)都會被同行或者技術開發(fā)人員說實現(xiàn)不了。有些產(chǎn)品經(jīng)理是有研發(fā)背景的，即在轉(zhuǎn)行做產(chǎn)品經(jīng)理之前，有從事過開發(fā)工作，這樣就非常的有優(yōu)勢，如果之前的開發(fā)工作與現(xiàn)在產(chǎn)品所需的技術語言是一樣的話，就比較完美了，可以在設計的時候就進行一定程度的實現(xiàn)性和可行性考慮，評估所設計的功能是否可以在現(xiàn)有條件和資源下實現(xiàn)，也能在開發(fā)人員的系統(tǒng)設計說明書評審會上聽懂，可以大致了解是否符合要求。

技術開發(fā)人員都比較喜歡和同行交流的，就像我們自己喜歡和產(chǎn)品經(jīng)理同行交流一樣，因此做過開發(fā)的產(chǎn)品經(jīng)理在和開發(fā)人員的溝通上有優(yōu)勢，但需要注意的是，千萬不能不懂裝懂，不要以為自己做過開發(fā)了不起，就指手畫腳的參與系統(tǒng)設計，這樣反而會令人反感，要記住你的技術背景只能停留在產(chǎn)品設計階段和PRD溝通階段，不要過多的給出技術方面的意見或建議，術業(yè)有專攻，況且你都轉(zhuǎn)行了，說不定你所知道的東西已經(jīng)過時了。

沒有研發(fā)背景的產(chǎn)品經(jīng)理就需要修煉了，其實也不需要去學習開發(fā)技術，但是要知道一些專業(yè)術語，比如要知道緩存、JS腳本、Ajax、數(shù)據(jù)庫、存儲過程、BI等等名詞到底是什么東西，否則你會發(fā)現(xiàn)你在和開發(fā)人員溝通的時候會一愣一愣的，因為他們說的你聽不懂。學習的時候要有針對性，比如公司產(chǎn)品都是采用JAVA開發(fā)的，那就去了解一下JAVA相關的基礎知識，數(shù)據(jù)都都是采用MYSQL的，那就去簡單了解一下這個數(shù)據(jù)庫相關的知識，我們的目標是能聽懂開發(fā)人員說的話，以免陷于被動。如果讓開發(fā)人員發(fā)現(xiàn)他說了半天，你都沒有聽明白，如果要他講第二遍或者一一解釋一下，估計首先會有點不耐煩，其次會有點嫌棄你了，呵呵。

從我目前的經(jīng)驗來看，以下這些技術點是產(chǎn)品經(jīng)理應該掌握的，這里不說“必須掌握”，確實是因為有例外存在。

SQL的讀和寫

在大數(shù)據(jù)時代，產(chǎn)品經(jīng)理幾乎天天都要和數(shù)據(jù)打交道，數(shù)據(jù)的來源有很多，但大部分肯定都是存儲在數(shù)據(jù)庫里面的，這時要做分析數(shù)據(jù)的話，數(shù)據(jù)分析能力是體現(xiàn)在拿到數(shù)據(jù)之后的，前提是你要拿到數(shù)據(jù)，這時就和SQL有關系了。

大公司數(shù)據(jù)倉庫建設比較完備，有較為完善的數(shù)據(jù)管理系統(tǒng)，且有專門的數(shù)據(jù)維護人員，俗稱BI或者DA，即做商業(yè)智能和數(shù)據(jù)處理加工的。在這種條件比較優(yōu)越的公司，常規(guī)的取數(shù)需求都可以提交給這些專業(yè)人士處理，如日常的分析報表、項目開展所需要的基礎數(shù)據(jù)等，只要說明清楚取數(shù)邏輯和所需要的字段就可以了。但平時的一些產(chǎn)品分析所需數(shù)據(jù)的獲取，以及一些指標考核項的數(shù)據(jù)就需要你自己動手了。好一點的情況下，你可以央求BI給你寫一個SQL語句出來，然后根據(jù)需要你自己改改；次一點的情況下，BI會將一些表結構說明給到你，然后你自己去組織表關聯(lián)取數(shù)；最差的情況就是啥都沒有，你自己去取數(shù)系統(tǒng)里面摸索著取數(shù)。而在小公司，產(chǎn)品經(jīng)理可以讓開發(fā)人員幫你取數(shù)，但你要是頻繁需要取數(shù)的，我想你也不好意思老開口，畢竟會影響開發(fā)人員的本職工作。自己動手豐衣足食，而且因為小公司數(shù)據(jù)系統(tǒng)建設不完善，最好的情況就是上面說的第二種，有表結構說明給你參考。

上面這些場景就要求產(chǎn)品經(jīng)理需要懂SQL語言。這里首先是要能看懂SQL，比方說你是求別人幫你取數(shù)的，但看了數(shù)據(jù)總感覺不對，這時你就需要去看看人家寫的SQL對不對，畢竟你自己才最清楚取數(shù)需求是什么。看懂了發(fā)現(xiàn)有錯誤的地方，還要會改，特別是別人給你一段有相似取數(shù)功能的SQL語句時，要能手動改改之后適合你自己的取數(shù)需求。其次是要知道怎么寫SQL，這就要求產(chǎn)品經(jīng)理懂得SQL語言的語法和一些常用的函數(shù)，比如日期函數(shù)、格式轉(zhuǎn)換函數(shù)、數(shù)學函數(shù)、字符串函數(shù)等等，最常見和最基本的都要掌握和靈活運用。

個人強烈建議產(chǎn)品經(jīng)理同行們都學習一下SQL，這樣在日常工作當中會方便很多。需要注意的是，SQL語言有T-SQL（Transact-SQL）和PL/SQL（Procedural Language/SQL）兩種，需要根據(jù)不同的數(shù)據(jù)庫類型，有針對性的去學習。比如說產(chǎn)品采用的是SQLServer數(shù)據(jù)庫，那就需要學習T-SQL；如果采用的是Oracle或者Mysql數(shù)據(jù)庫，就需要學習PL/SQL，兩種語言在語法上差別比較大，大部分情況下都不能混用。另外Oracle和Mysql數(shù)據(jù)庫在應用PL/SQL的時候，會有一些函數(shù)有使用上的差異，需要注意一下。有人會說現(xiàn)在還有一些非關系型數(shù)據(jù)庫，如MangoDB之類的，這種數(shù)據(jù)庫基本不支持SQL語言去查詢，而且里面存儲的都是非關系型的數(shù)據(jù)，也不需要查詢出來做分析。

UML和E-R圖

早些年，產(chǎn)品經(jīng)理這個名詞還沒有流行的時候，做類似行當?shù)娜艘话惴Q為“需求分析師”，傳統(tǒng)的軟件需求分析師的一項必備技能就是用UML畫用例圖，當然這個現(xiàn)在也適用，用例圖對于說明需求來說，作用還是很明顯的，至少開發(fā)能看的比較明白。現(xiàn)在隨著思維導圖和原型的星期，用例圖逐漸的有點被淘汰的意思，但很多開發(fā)人員還是會用UML來畫系統(tǒng)設計圖，如活動圖、狀態(tài)圖、協(xié)作圖等，產(chǎn)品經(jīng)理需要了解一下這些，以便能在設計評審上看懂這些圖。

E-R圖也稱實體-聯(lián)系圖(Entity Relationship Diagram)，提供了表示實體類型、屬性和聯(lián)系的方法，在數(shù)據(jù)表關系設計上應用比較多。一個產(chǎn)品的數(shù)據(jù)存儲，肯定不會只有一張數(shù)據(jù)表，而是由多張數(shù)據(jù)表通過關系關聯(lián)起來的，相互之間的這種關系就可以用E-R圖來表示，可以從中看出各表之間關聯(lián)的主鍵和外鍵分別是什么，哪些字段值唯一等。

UML圖和E-R圖在系統(tǒng)設計當中經(jīng)常出現(xiàn)，產(chǎn)品經(jīng)理要能看懂其所表達的意思。你和開發(fā)人員講需求設計的時候需要面面俱到，每個細節(jié)都會講到，但開發(fā)人員跟你講系統(tǒng)設計的時候，可是能簡則簡，你看不懂是你的事情，他們可是按這個開發(fā)的。

移動端的設計規(guī)范

這里包含產(chǎn)品設計規(guī)范和編碼規(guī)范，無論是Android還是IOS都有自己特定的規(guī)范，移動端的產(chǎn)品經(jīng)理在設計產(chǎn)品的時候就需要先了解清楚這些規(guī)范的內(nèi)容，和一些技術實現(xiàn)的方式。移動端的技術實現(xiàn)相對比較可控和有限，多了解一些技術有助于進行有效的產(chǎn)品設計。盲目的設計要么實現(xiàn)不了，要么最終無法通過審核，是不可取的。移動端的一些特效也需要清楚，如拖拽、滑動、下拉、手勢等，產(chǎn)品經(jīng)理如果不了解這些，都設計不出操作體驗很好的產(chǎn)品來。另外諸如不能獲取用戶的某些敏感數(shù)據(jù)等注意事項，都需要在產(chǎn)品設計時就考慮到。這塊具體的還是要看場景來決定。

基礎的技術名詞

如前面最開頭所提到的那些，如緩存、Cookie、Ajax、中間件、數(shù)據(jù)庫等等名詞，需要去了解一下其所表示的意思，開發(fā)人員在溝通的時候會經(jīng)常提到這些，如果你聽不懂，就會比較杯具。另外掌握如緩存、Cookie的使用，還可以在產(chǎn)品后端邏輯中添加一些功能，比如讓Cookie記錄用戶填寫的用戶名，下次再來登錄時不要重復輸入；用緩存記錄用戶的登錄驗證信息，在一段時間內(nèi)不需要用戶重新登錄等等。

還有就是要區(qū)分學習一下產(chǎn)品實現(xiàn)的開發(fā)語言，比如Java、PHP、.Net等，了解一些基本的知識點，如部署方式，運行載體等，比如常說的LAMP是指Linux+Apache+Mysql+PHP的組合；了解一些腳本語言，如JS腳本、CSS等。這里需要提一下的是，產(chǎn)品經(jīng)理最好懂HTML，注意不是HTML5，當然要是懂H5就更好了，HTML是最基本的網(wǎng)頁腳本語言，有時候看不懂某個頁面的邏輯時，可以點擊右鍵屬性—“查看網(wǎng)頁源代碼”來看一看。

上面所提到的這些是個人覺得比較基礎也比較容易掌握的技術點，特別是SQL，強烈建議產(chǎn)品經(jīng)理們都學習一下。不過這是一個持續(xù)學習的過程，只要你不轉(zhuǎn)行，學習了之后會一直受益。