電動車廠特斯拉（Tesla）週二發佈新版 Model S 轎車和 Model X 多功能跑車，型號都為P100D，較P90D更為高端。這兩款新車型將配備更加強大的電池組，可令Model S車型成為世界上加速最快的批量生產汽車。  
  Model S P100D和Model X P100D在啟動加速方面和電池續航方面都有了突破性提升。其中Model S P100D配備一個100kWh的電池組，在 Ludicrous （超級加速）模式下從靜止加速至時速60英里僅需2.5秒，相比之下P90D在Ludicrous模式下所需的加速時間為2.8秒。   特斯拉宣稱Model S P100D在啟動加速方面媲美全球頂級超跑，是全球量產型號中加速最快的一個。此外，Model S P100D EPA有效行駛里程為315英里。另一輛Model X P100D車型的車重更大，從靜止加速至時速60英里僅需2.9秒，單次充電續航里程將達289英里，略低於Model S P100D。售價方面，新Model S起始售價將為13.45萬美元，Model X的起始售價將為13.55萬美元。   文章來源: IT之家

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

隨著年底苗栗頭份自強和新竹東勝兩家門市開幕，電動機車大廠 Gogoro 宣告在全國所有縣市都設有服務據點。對做為機車業後起之秀的 Gogoro 而言，也算是達成了一項里程碑。

Gogoro 在 2019 年成功插旗澎湖、苗栗、基隆、東勢、沙鹿、鹿港、草屯、東港、羅東、台東等地，讓每個縣市都至少有一個服務據點。Gogoro 到目前為止設立了 125 個服務據點，雖然還比不上其他機車大廠綿密的服務網絡，但至少不會讓服務據點成為致命傷。2020 年將持續加速拓展服務範圍，預計再設置超過 60 個服務據點，相當於平均每週就設立 1.2 間。拓點計畫將著重於加速設立服務中心，以舒緩各地的車主的維修保養服務需求。

Gogoro 資深行銷總監陳彥揚表示：「隨著不斷增加的 Gogoro 車主數，Gogoro 也加緊腳步規劃通路策略的佈局，於明年大幅拓展服務中心以提供廣大車主完善維修保養服務。另一方面，也積極推動智慧雙輪推廣站，讓傳統車行也有機會加入電動機車推廣行列，更協助 Gogoro 創造與消費者的多元接觸點，提升品牌與產品溝通的廣度。」

除了持續拓展加盟店以外，Gogoro 在 5 月也成立了智慧雙輪推廣站，讓機車行能以更低的門檻有機會銷售電動機車。Gogoro 將提供機車行基礎輔銷物及教育訓練，機車行也無須負擔產品庫存壓力。目前已有近千家機車行表達加入意願，預計將在 2020 年 1 月舉辦對外說明會。

Gogoro 也配合工業局機車行轉型課程，提供專業講師以及課程，讓傳統車行技師學習電動機車維修技術，並在機車行提供簡易維修服務或開立電動機車門市。目前已完成 20 堂課程及協助超過 600 位學員完成訓練，2020 年將持續協助政府開設第二階段轉型課程。

（合作媒體：。首圖來源：Gogoro）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

最近在電動車主社群流傳著一句話，「想買電動車，先去當主委」，反映出其實目前住宅大樓要安裝充電設備的難題，也有不少車主分享甘苦談與教戰攻略，幫助其他車友。看準了電動車議題，有些建商已開始提前規劃電動車位，期望以此吸引高消費力客群進住。

想像一下，你終於如願以償住進全新落成的華廈大樓，有漂亮的花園、24 小時警衛與管理、平面式停車位與一應俱全的公共設施，但當你想替電動車充電時，只能排隊去搶地下 1 樓、全社區只有兩支的充電槍。即使想在自己車位安裝充電槍，不僅要說服管委會同意，依據大樓結構，甚至可能要召開全體區權會才能過關。

隨著車廠陸續宣布停止推出新款燃油車，未來 10 年，會有越來越多車主購入電動車，這些人都有在家充電的需求，然而卻很少有建案能解決這個問題，大部分新建案都是依照法規需求，配置最低數量要求的充電車位，甚至是與訪客車位混用。

台北的豪宅指標「帝寶」就曾為了住戶要在地下停車場裝設充電樁，被管委會以「擔心起火」為由拒絕，歷經一番爭論最終才同意放行。正因如此，許多電動車主才會說，要買電動車，先去當主委，有了主委帶頭推動，才比較好說服管委會同意放行施工。

為了爭取安裝充電樁，電動車友分享的招式也是五花八門，甚至出現「暗黑兵法」，向管委會提出「禁止停車場裝設充電設備」，利用這個反向操作讓管委會「不反對」安裝充電樁，而成功闖關。

身為看熱鬧的人，聽了覺得有趣，但電動車主可能笑著笑著就哭了。歷經千辛萬苦爭取後，安裝充電樁的費用說貴不貴，但也不便宜，以一般大樓的電表集中設置在地下 1 樓來算，安裝費用與車位到電表距離成正比，如果車位也在 B1，費用可能在 2 萬元左右，如果車位在 B3，那費用可能就接近 3 萬元。不精準的估算約是每公尺 1,000 元，實際費用要看現場環境決定，安裝費用超過 5 萬元的也不是沒有。

預留管線將成為未來建案標配？

目前有幾家建商已看準這個需求，提出新的解決方案，包括希華、璞園和遠雄等建商，都針對電動車位特別規劃，當作一個科技賣點。

《建築法》修改之前，新建案電動車位的比例要求很低，大部分都只有兩個，而這幾家建商提出優於法規的設計，以遠雄今年即將完工的高雄新灣區建案為例，就規劃了 70 個電動車位，與台電合作，幫這些車位預留充電設備的線路與孔洞，同時也準備了足額的電流負載，屋主只要購買電動車時，讓車廠到現場安裝充電設備即可。

「我們的客戶中，已有 4 台保時捷 Taycan，還有好幾台特斯拉，這些客戶未來就完全不用煩惱充電問題。」遠雄房地產管理處總監呂穎表示，由於這建案是飯店與住宅結合，目前還計劃與車廠合作，在 1 樓或附近建設新的直流充電站，提供住戶與旅客雙重便利。

然而，電動車位對建商來說其實是雙面刃，可吸引高消費力客群入住，但相關電力配套其實不容易達成，「通常重劃區的電力規劃會比較有餘裕，老社區即使蓋新大樓也未必負荷得了，即使如此，假如我們全棟都做成電動車位也一樣受不了，因為尖峰時期的用電量幾乎等於一座大巨蛋。」呂穎笑說，真要這樣的話，隔壁可能要蓋一座變電所，到時候反而沒人要買屋了。

以特斯拉充電樁為例，Model 3 充電時需要的電流量是 32 安培，如果一個社區 500 個車位都在充電，瞬間負載就高達 16,000 安培，相當於整個社區住宅的最大用電量，因此若沒有完整配套，是不可能實現的。

從現實角度來說，短期內一般建案還是會以法規最低要求為標準，以減少成本，只有在高價位豪宅等級建案才有可能看到電動車位成為標配。想在大樓停車場充電的車主，如果沒有入主豪宅的打算，還是先認命與管委會溝通吧！

（合作媒體：。首圖來源：）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

《MINING.com》6月12日報導，國際銅業協會（International Copper Association）最新報告表示，電動汽車的產業增長，可望令未來十年該產業的銅需求量大幅增長，預估將從2017年的18.5萬噸九倍增長至2027年的174萬噸，主要因為電動汽車較傳統汽車使用更多銅的影響。報告指出，除了價格昂貴的貴金屬之外，銅的導電性居所有金屬之冠，將會在電動汽車產業中扮演重要角色，並且銅也是100%可以回收的材料。

報告指出，傳統汽車生產每輛約會使用到23公斤的銅，但油電混合電動車（HEV）的銅用量就會接近倍增至40公斤，插電式油電混合電動車（PHEV）的銅用量更將達到60公斤，因其電池較傳統的油電混合電動車更大。至於完全由電池驅動的純電動車（BEV），每輛將會用到83公斤的銅。體積更大的油電混合電動巴士銅用量會達到89公斤，而完全由電池驅動的純電動巴士，每輛將會用到224-369公斤的銅，完全取決於其電池的大小。

除了汽車本身以外，包括充電樁等電動車產業的基礎設施也都會用到銅，每個充電樁將會使用到0.7公斤的銅，而如果是具備快速充電功能的充電樁，其銅用量將會達到8公斤。此外，未來如果獨立能源汽車像是太陽能汽車進入市場的話，汽車市場的銅需求量還會增長得更快，因太陽能汽車的太陽能發電系統同樣依賴相當數量的銅來運作。

政府政策將是推動電動車產業發展的一大助力。2016年，大陸電動車的銷量略高於50萬輛，而北京當局已經制定至2020年將達成年銷量200萬輛的目標。印度政府則是宣布，2030年以後，該國所銷售的汽車都必須是電動車。淡水河谷公司（Vale SA）總裁兼執行長費慕禮（Murilo Ferreira）預估，可能在五年之內，七大工業國所生產的汽車就會有一半是電動車。

美國全球投資者公司（US Global Investors）執行長兼投資長霍姆斯（Frank Holmes）此前表示，全球替代能源的爆發增長將會帶動銅的需求。霍姆斯指出，新的發電技術通常較傳統的發電使用更多的銅，如每百萬瓦的風力發電產能就會用到約3.6公噸的銅。此外，混合動力車以及電動車的銅使用量也較傳統汽車高出兩到三倍；平均每輛汽油車所使用的銅線約為55磅，混合動力車則達到110磅，電動車更是高達165磅。

（本文內容由授權使用。圖片出處：public domain CC0）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

進入2017年以來，上海市新能源汽車推廣應用和產業發展繼續保持高增長，1-5月新能源汽車推廣上牌數量達到10699輛。據瞭解，目前在上海市場上銷售的新能源車型累計超過100款，其中本地品牌占比為35%，其他省市品牌占比達到65%，市場累計推廣前5位的品牌依次為比亞迪、榮威、北汽、奇瑞、Tesla。

當前，上海已成為新能源汽車全球保有量最大的城市，吉利汽車自然不會放過這個巨大的市場。在最近上海市經信委公佈的4批新能源汽車備案資訊表中，吉利分別在第三批、第四批目錄中均有車型進入。據悉，吉利進入上海市新能源汽車備案資訊表中的車型為吉利帝豪EV300及吉利帝豪PHEV。

吉利帝豪EV300自推出以來，頗受市場的歡迎，今年5月還登頂了新能源汽車單車銷量排行板的第一位，而帝豪PHEV作為吉利旗下首款插電式混合動力車型，自公佈以來也是備受關注。

據瞭解，吉利帝豪PHEV外觀上與吉利帝豪EV基本相同。內飾方面，帝豪PHEV配備三輻式真皮方向盤並集成了CCS定速巡航、多媒體播放、語音控制等控制按鈕。而與帝豪EV不同的是，在中控部分帝豪PHEV增加了旋鈕式檔位，使車輛可在純電動、混合動力等模式中進行切換，增強了操作的便利性及駕駛體驗。

最亮眼的部分是帝豪PHEV採用了被稱為“聯擎”的功率分流式混合動力技術，搭載代號為JLγ-4G15H的1.5L發動機與兩台高性能電機和11.3kWh的三元鋰電池組組成的插電式混合動力系統。新車最高時速可達175km/h，NEDC工況油耗1.5L/100km，HEV模式下綜合工況油耗5.1L/100km，NEDC工況下純電續航里程61km。

作為全國插電式混合動力最大銷售城市，吉利帝豪PHEV本次順利進入上海新能源汽車目錄無疑是個極好的信號。為了與各位大咖搶佔市場份額，吉利汽車將攜帝豪EV300，帝豪PHEV亮相2017上海國際新能源汽車產業博覽會。其中帝豪PHEV是進入上海新能源汽車目錄後，首度亮相上海。

據瞭解，2017上海國際新能源汽車產業博覽會是由充電設施線上網、廣東省充電設施協會、廣東省新能源汽車產業協會、中國土木工程學會城市公共交通學會和振威展覽股份聯合舉辦，展示面積達45000平米，參展企業涵蓋了整車、核心三電（電池、電機、電控）、充電設備等產業板塊，是我國新能源汽車產業領域最專業的展覽展示和技術交流的綜合性展會平臺。

除吉利外，比亞迪、申龍客車、珠海銀隆、上汽集團、上饒客車、中植新能源、中通、江淮、眾泰、知豆、南京金龍、成功汽車、新吉奧集團、瑞馳新能源、福汽新龍馬等新能源汽車企業，以及精進電動、英威騰、東風電機、力神、沃特瑪、國軒高科、地上鐵、特來電、科陸、巴斯巴、萬馬專纜、奧美格、瑞可達等核心三電及零部件知名企業將亮相本次展會。

參觀預登記，請點擊：

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

重新定義受控與非受控組件的邊界

對非受控組件與受控組件作了如圖中下劃線的邊界定義。一經推敲, 該定義是缺乏了些完整性和嚴謹性的, 比如針對非表單組件(彈框、輪播圖)如何劃分受控與非受控的邊界? 又比如非受控組件是否真的如文案上所說的數據的展示與變更都由 dom 自身接管呢?

在非受控組件中, 通常業務調用方只需傳入一個初始默認值便可使用該組件。以 Input 組件為例:

// 組件提供方
function Input({ defaultValue }) {
  return <input defaultValue={defaultValue} />
}

// 調用方
function Demo() {
  return <Input defaultValue={1} />
}

在受控組件中, 數值的展示與變更則分別由組件的 state 與 setState 接管。同樣以 Input 組件為例:

// 組件提供方
function Input() {
  const [value, setValue] = React.useState(1)
  return <input value={value} onChange={e => setValue(e.target.value)} />
}

// 調用方
function Demo() {
  return <Input />
}

有意思的一個問題來了, Input 組件到底是受控的還是非受控的? 我們甚至還可以對代碼稍加改動成 <Input defaultValue={1} /> 的最初調用方式:

// 組件提供方
function Input({ defaultValue }) {
  const [value, setValue] = React.useState(defaultValue)
  return <input value={value} onChange={e => setValue(e.target.value)} />
}

// 調用方
function Demo() {
  return <Input defaultValue={1} />
}

儘管此時 Input 組件本身是一個受控組件, 但與之相對的調用方失去了更改 Input 組件值的控制權, 所以對調用方而言, Input 組件是一個非受控組件。值得一提的是, 以非受控組件的使用方式去調用受控組件是一種反模式, 在下文中會分析其中的弊端。

如何做到不管對於組件提供方還是調用方 Input 組件都為受控組件呢? 提供方讓出控制權即可, 調整代碼如下:

// 組件提供方
function Input({ value, onChange }) {
  return <input value={value} onChange={onChange} />
}

// 調用方
function Demo() {
  const [value, setValue] = React.useState(1)
  return <Input value={value} onChange={e => setValue(e.target.value)} />
}

經過上述代碼的推演后, 概括如下: 受控以及非受控組件的邊界劃分取決於當前組件對於子組件值的變更是否擁有控制權。如若有則該子組件是當前組件的受控組件; 如若沒有則該子組件是當前組件的非受控組件。

職能範圍

基於調用方對於受控組件擁有控制權這一認知, 因此受控組件相較非受控組件能賦予調用方更多的定製化職能。這一思路與軟件開發中的有異曲同工之妙, 同時讓筆者受益匪淺的 也是類似的思想。

藉助受控組件的賦能, 以 Input 組件為例, 比如調用方可以更為自由地對值進行校驗限制, 又比如在值發生變更時執行一些額外邏輯。

// 組件提供方
function Input({ value, onChange }) {
  return <input value={value} onChange={onChange} />
}

// 調用方
function Demo() {
  const [value, setValue] = React.useState(1)
  return <Input value={value} onChange={e =>
    // 只支持數值的變更
    if (/\D/.test(e.target.value)) return
    setValue(e.target.value)}
  />
}

因此綜合基礎組件擴展性與通用性的考慮, 受控組件的職能相較非受控組件更加寬泛, 建議優先使用受控組件來構建基礎組件。

反模式 —— 以非受控組件的使用方式調用受控組件

首先何謂反模式? 筆者將其總結為增大隱性 bug 出現概率的模式, 該模式是最佳實踐的對立經驗。如若使用了反模式就不得不花更多的精力去避免潛在 bug。官網對反模式也有很好的。

緣何上文提到以非受控組件的使用方式去調用受控組件是一種反模式? 觀察 Input 組件的第一行代碼, 其將 defaultValue 賦值給 value, 這種將 props 賦值給 state 的賦值行為在一定程度上會增加某些隱性 bug 的出現概率。

比如在切換導航欄的場景中, 恰巧兩個導航中傳進組件的 defaultValue 是相同的值, 在導航切換的過程中便會將導航一中的 Input 的狀態值帶到導航二中, 這顯然會讓使用方感到困惑。

// 組件提供方
function Input({ defaultValue }) {
  // 反模式
  const [value, setValue] = React.useState(defaultValue);
  React.useEffect(() => {
    setValue(defaultValue);
  }, [defaultValue]);
  return <input value={value} onChange={e => setValue(e.target.value)} />;
}

// 調用方
function Demo({ defaultValue }) {
  return <Input defaultValue={defaultValue} />;
}

function App() {
  const [tab, setTab] = React.useState(1);
  return (
    <>
      {tab === 1 ? <Demo defaultValue={1} /> : <Demo defaultValue={1} />}
      <button onClick={() => (tab === 1 ? setTab(2) : setTab(1))}>
        切換 Tab
      </button>
    </>
  );
}

如何避免使用該反模式同時有效解決問題呢? 官方提供了兩種較為優質的解法, 將其留給大家作為思考。

1. 方法一: (更為推薦)
2. 方法二:

歡迎關注

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

一、應用場景

一般情況下我們對springboot應用打包時使用springboot的maven插件spring-boot-maven-plugin的maven進行打包，打包完成得到一個fatjar，fatjar的優點是可以直接運行，缺點是體積太大，不利於傳輸，springboot應用打出來的fatjar體積少則幾十M，多則上百M，在往服務器部署傳輸時十分不便，可能只改了某個類文件，都需要重新將整個fatjar重新傳輸一次，特別是走公網傳輸的時候，可能上傳速度只有幾百甚至幾十KB，而整個fatjar中真正我們項目的代碼文件可能也就幾百KB或幾兆的大小，所以有必要將fatjar中的依賴庫與我們項目的class進行分離打包，這樣每次更換項目class就方便很多，而將配置文件也分離出來的原因在於我們可能經常需要更改配置文件的內容，如果放在fatjar中這樣修改是非常不方便的，所以也需要將配置文件也分離出來。

 >  fatjar 即將項目需要的所有依賴庫及配置文件等打進一個jar或war，該文件可直接運行

二、配置

2.1 POM配置

下面對pom.xml進行配置，來實現分離打包，配置如下

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>chenyb</groupId>
    <artifactId>demo</artifactId>
    <version>v1.2-release</version>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.1.6.RELEASE</version>
    </parent>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <!-- springboot 打包插件 -->
            <!--
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <configuration>
                    <mainClass>com.xx.xx</mainClass>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>repackage</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            -->

            <!-- maven 打包插件 -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <configuration>
                    <archive>
                        <manifest>
                            <addClasspath>true</addClasspath>
                            <!-- MANIFEST.MF 中 Class-Path 加入前綴 -->
                            <classpathPrefix>lib/</classpathPrefix>
                            <!-- jar包不包含唯一版本標識 -->
                            <useUniqueVersions>false</useUniqueVersions>
                            <!-- 指定入口類 -->
                            <mainClass>cn.test.DemoApplication</mainClass>
                        </manifest>
                    </archive>
                    <outputDirectory>${project.build.directory}</outputDirectory>
                </configuration>
            </plugin>

            <!-- 拷貝依賴 -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-dependency-plugin</artifactId>
                <executions>
                    <execution>
                        <id>copy-dependencies</id>
                        <phase>package</phase>
                        <goals>
                            <goal>copy-dependencies</goal>
                        </goals>
                        <configuration>
                            <outputDirectory>${project.build.directory}/lib</outputDirectory>
                            <overWriteReleases>true</overWriteReleases>
                            <overWriteSnapshots>true</overWriteSnapshots>
                            <overWriteIfNewer>true</overWriteIfNewer>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

        </plugins>
    </build>

</project>

關鍵配置說明：

(1) 去掉了spring-boot-maven-plugin打包插件

(2) 添加 maven-jar-plugin （maven標準打包插件）

(3) maven-dependency-plugin（依賴拷貝插件，主要用於將maven依賴庫拷貝出來）

插件具體的配置，pom.xml中已添加備註說明

2.2 打包

執行maven package 命令進行打包，得到的結果如下

 將 lib目錄 及 項目jar 文件拷貝到同一目錄下，我為了測試方便，先全部拷貝到桌面上，（放置服務器上時也需保證在同一目錄下）

 打開demo-v1.2-release可以看到，並沒有將依賴jar打進來，大小隻有不到4KB

2.3 config目錄創建

以上做完還還需要將項目配置文件拷貝出來，在與jar包平級目錄建立config目錄，將項目中的application.properties或yaml文件拷貝進來

  config 下的文件

經過以上步驟，全部配置完畢，下面進行一下簡單的測試

三、測試

 為了保證加載的是外部config目錄的配置文件，我將application-test.yaml中的server.port改為8085， 打開命令行輸入

C:\Users\Administrator\Desktop>java -jar -Dspring.profiles.active=dev -Dspring.location.config=config/ C:\Users\Administrator\Desktop\demo-v1.2-release.jar

回車運行，能正常啟動說明外部依賴可以正常加載進來

 可以看到啟動完成后tomcat監聽端口為8085，說明外部配置加載成功。

PS : 如果外部配置文件加載失敗，會使用項目jar中的配置文件，如下圖，也就是啟動後會是8080端口

application-dev.yaml中配置的端口是8080

而我已將外部config目錄下application-dev.yaml中端口做了修改，使用外部配置文件啟動後會是8085端口

四、一點小坑

默認情況下window命令行打開后，是在當前用戶目錄下，像這樣

 而我的config、lib、項目jar拷貝在桌面上，實際路徑是

一開始我在  C:\Users\Administrator> 直接執行下方命令，一直加載不到配置文件

java -jar -Dspring.profiles.active=dev -Dspring.location.config=config/ C:\Users\Administrator\Desktop\demo-v1.2-release.jar

原因就在於程序與配置文件不在同一目錄下，我在C:\Users\Administrator>運行啟動命令，而程序實際目錄在 C:\Users\Administrator\Desktop> 下，因為程序使用了絕對路徑，可以找到文件，所以程序的實際運行路徑為C:\Users\Administrator\Desktop，而我使用的配置 spring.location.config=config/ 使用的是相對路徑，，這個相對路徑又是相對 C:\Users\Administrator> 目錄，所以就會出現找不到配置文件的情況。

解決辦法一：

命令行切換到 C:\Users\Administrator\Desktop 目錄，即項目jar所在目錄，運行 java -jar 命令

解決辦法二：

將config拷貝到C:/Users/Administrator下，保證C:/Users/Administrator相對路徑下存在config目錄及配置文件（該方法可解決問題，但是不建議）

解決方法三：

spring.location.config=config/ 處使用絕對路徑，即C:/Users/Administrator/Desktop/config/ 

所以很重要一點，一定保證 執行命令 的目錄 與項目jar、lib、config都在同一目錄下。

五、完整demo地址

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

最近寫了一個工具（比較兩套測試環境mysql數據庫中表、表字段、索引的差異，基於python）通過文章簡單介紹下工具的相關內容

1. 工具名稱
2. 主要功能
3. 具體使用方法
4. 部分實現代碼
5. 後續

一、工具名稱：

dbstructsync （python庫）

二、主要功能：

比較兩套環境中mysql指定庫中表、表字段及索引的差異，返回同步的sql ，裡面包含建表，修改索引，修改字段的sql .

A環境的數據庫db 作為sourcedb， B環境的數據庫db targetdb ，程序邏輯比較的是 sourcedb 與targetdb 的差異，然後返回一個list的數據類型 

list中包含新建表sql，修改、增加字段sql, 刪除、新增索引sql 

現在總共有3個版本，0.0.1 和0.0.2 存在一定的bug, 所以請使用最新的0.0.3版本

其他說明：由於是剛完成不久的程序，所以暫時不對最終結果sql進行執行，避免對使用過程中產生不好的影響，這個版本大家可以通過python 自行選擇需要執行哪些操作；隨着之後程序的逐步深入修改和演變，會將執行sql這一步也都加進去

同時也會優化使用方式，讓使用這個工具的小夥伴更容易操作

三、具體使用方法：

1、 pip install  -i https://pypi.python.org/pypi  dbstructsync   

在代碼里引入使用，

from DbStructSync import cli 

result=cli.db_sync(sourcedb, targetdb) 
#sourcedb,targetdb是兩個dict的參數，具體參數看下面
# 這裏得到的    result = ['use 庫;', 
#             'CREATE TABLE `test_async` (\n  `test_async` #varchar(30) NOT NULL,\n  `aa` varchar(400) DEFAULT NULL,\n  #PRIMARY KEY (`test_async`)\n) ENGINE=InnoDB DEFAULT #CHARSET=utf8;',
#             'drop index `index_chaxx` on chanxx_auto_puxx_conf;',
#             'create index `index_chaxx` on #chanxx_auto_puxx_conf(`channel_nxx`,`channel_prxx`) USING #BTREE;']
#result 中包含  use 庫；
#              如果有少的表，會有 create table的數據; 如果有不同的索引，會#存在drop index 和create index的sql;
#              如果有不同的字段，會有alter table的sql ;
#只需要對這個結果，再通過pymysql的一些數據庫操作就可以保證 sourcedb #的內容與taragetdb一致。

2、同時還支持命令行操作，代碼寫入到x.py代碼中

result = cli.db_sync_commandline()
python x.py --source  host=10.1.1.x,port=3306,user=root,passwd=root,db=investx --target host=10.1.1.x,port=3306,user=root,passwd=root,db=investx

命令行中  –source  key=value;key2=value2;key3=value3  –target key=value;key2=value2;key3=value3

–source, –target 是兩給必輸的參數，後續的值會作為一個dict類型傳入程序。 –source是源庫的信息， –target是目標庫的信息

還包括其他幾個命令參數 –only-index , –only-fields ; –only-index 只比較索引差異， –only-fields 只比較字段差異， 非必填，默認都為False 

四、部分實現代碼：

def diff_tables(sourcetable, targettable):
    '''

    :param sourcetable:  源數據庫的表名列表
    :param targettable:  目的數據庫的表名列表
    :return: 返回dict，包含三種結果，源庫多的表，目標庫多的表，相同的表
    '''
    logger.info('開始比較兩個庫中表的差異,源庫表{}，目標庫表{}'.format(sourcetable, targettable))
    table_result={}
    if not isinstance(sourcetable, list) or not isinstance(targettable, list):
         raise  TypeError('sourcetable , targettable的類型不是list')
    source_diff = set(sourcetable) - set(targettable)
    target_diff = set(targettable) - set(sourcetable)
    same_tables = set(sourcetable)& set(targettable)
    table_result['source'] = source_diff
    table_result['target'] = target_diff
    table_result['same'] = same_tables
    logger.info('兩個庫中表的差異結果{}'.format(table_result))
    return  table_result
 

def  diff_indexs_fields(sourcesql, targetsql, type=1):
    '''
    :param sourcesql: 源數據庫表的創建sql
    :param targetsql: 目標數據表的創建sql
    :return: 記錄下索引不一致的地方
    '''
    result = {}
    logger.info('解析語句中的索引字段，並進行比較索引')
    sourcesql = parse_str(sourcesql)  # 從括號中提取需要的內容
    #logger.info('從括號中提取出來的信息數據{}'.format(sourcesql))
    sourcesql = lists2str(sourcesql)  #將list轉換為str，並對數據的空格數據進行處理
    logger.info('解析完的數據的信息{}'.format(sourcesql))
    sourcesql = sourcesql.split('\n') #將str按照'\\n'進行分割
    logger.info('解析完數據之後的信息{}'.format(sourcesql))
    targetsql = parse_str(targetsql)
    targetsql = lists2str(targetsql)
    targetsql = targetsql.split('\n')
    if type ==1:
        source_index = parse_fields(sourcesql,type)
        target_index = parse_fields(targetsql,type)

        result= compare_indexs_field(source_index, target_index, type)
    elif type ==2:
        source_field_sql = parse_fields(sourcesql, type)
        target_field_sql = parse_fields(targetsql, type)
        result = compare_indexs_field(source_field_sql, target_field_sql, type)
    return  result

def dict2sql(dict_str):
    '''
    將解析完成的數據轉換為對應的可執行sql
    :param dict_str:
    :return:
    '''
    dict_str = copy.deepcopy(dict_str) # 做一個深度copy，可以放心的進行相關數據處理

    if not isinstance(dict_str, dict):
        raise  TypeError('調用方法{}參數不是dict類型，請確認'.format('dict2sql'))
    #獲取db名字
    for key ,value in dict_str.items():
        dbname = key
        logger.info('數據庫名{}'.format(dbname))
        for table, table_desc  in  value.get('source').items():
               if table =='create_table':
                   #create_table_sql = lists2str(table_desc)
                   dict_str[dbname]['source'][table] = table_desc
                   #其他的都是table的名字
                   logger.info('數據庫的修改語句:{}'.format(table_desc))
               else:
                  logger.info('對於索引和字段的解析原始數據{}'.format(table_desc))
                  if table_desc.get('index'):
                      create_index_sql_lists=[]
                      #create_index_sql_lists.append('use {};'.format(dbname))
                      index_lists= (table_desc.get('index'))
                      result_index= parse_comma_split(str(index_lists)[1:-1])
                      for i in result_index:
                           if i.strip().startswith('\'KEY'):
                               #print(i.strip())
                               index_values = parse_space_split(i.strip())
                               drop_index_sql= 'drop index {} on {}'.format(index_values[1],table )
                               if len(index_values)<=3:
                                  create_index_sql='create index {} on {}{} '.format(index_values[1], table, index_values[2])
                               else:
                                  create_index_sql='create index {} on {}{} {}'.format(index_values[1], table, index_values[2], ' '.join(index_values[3:]))
                               create_index_sql_lists.append(drop_index_sql)
                               create_index_sql_lists.append(create_index_sql)

                           if i.strip().startswith('\'UNIQUE KEY'):
                                 index_values = parse_space_split(i.strip())
                                 drop_index_sql = 'drop index {} on {}'.format(index_values[2], table)
                                 if len(index_values) <= 4:
                                     create_index_sql = 'create unique index {} on {}{} '.format(index_values[2], table,
                                                                                          index_values[3])
                                 else:
                                     create_index_sql = 'create unique index {} on {}{} {}'.format(index_values[2], table,
                                                                                               index_values[3],
                                                                                               ' '.join(index_values[4:]),
                                                                                               )
                                 create_index_sql_lists.append(drop_index_sql)
                                 create_index_sql_lists.append(create_index_sql)
                      logger.info('表{}解析出來的索引的修改sql{}'.format(table, create_index_sql_lists))
                      dict_str[dbname]['source'][table]['index'] = create_index_sql_lists
                  if table_desc.get('fields'):
                      create_fields_sql_lists=[]
                      #create_fields_sql_lists.append('use {};'.format(dbname))
                      modify_field_sqls = table_desc.get('fields').get('modify',None)
                      create_field_sqls=table_desc.get('fields').get('lose',None)

                      if modify_field_sqls:
                           for modify_field_sql in modify_field_sqls:
                               sql_indexs = parse_space_split(str(modify_field_sql)[0:-1])
                               #print(sql_indexs)
                               alter_fields_sql='alter table {} modify column {} {} {}'.format(table, sql_indexs[0],sql_indexs[1],' '.join(sql_indexs[2:]))
                               create_fields_sql_lists.append(alter_fields_sql)
                      if create_field_sqls:
                           for  create_field_sql in create_field_sqls:
                                sql_indexs = parse_space_split(str(create_field_sql)[0:-1])
                                create_fields_sql='alter table {} add column {} {}'.format(table, sql_indexs[0],' '.join(sql_indexs[2:]))
                                create_fields_sql_lists.append(create_fields_sql)
                      logger.info('表{}解析出來的字段的修改sql{}'.format(table,create_fields_sql_lists))
                      dict_str[dbname]['source'][table]['fields'] = create_fields_sql_lists

    return  dict_str  # 返回給一個全部是可執行sql的dict

五、後續：

1、對使用過程中遇到對bug進行修復

2、對代碼進行優化

3、增加其他相關功能，讓工具越來越好用

4、希望使用的小夥伴多提意見，未來成為一個好用的小工具

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

鹼性電池售價便宜、也比鋰電池更不容易起火燃燒，唯一缺點是無法重複充電使用。不過，新創公司Ionic Materials即將在本週四（8月3日）發表一項突破性的新發現，讓固態的鹼性電池成為鋰電池等高儲電科技的替代品，直接應用到PC、智慧型手機或電動車。

紐約時報1日報導（），Ionic發明的新技術，可讓鹼性電池重複充電，其推出的原型，最多已能充電400次。Ionic創辦人兼材料科學家Mike Zimmerman說，該公司開發的鹼性電池，目前雖比市面上的鋰電池還要重，但其成本優勢和更優秀的儲電能力，將彌補這項缺點。

不只如此，鋰電池的關鍵材料是鈷，不但毒害環境，非洲還有不少礦場違法使用童工採鈷，令人憂心。相較之下，鹼性電池使用的是蘊藏量相對豐富的鋅和錳。

另外，Ionic還修正鹼性電池的設計，以價格更為親民的鋁取代鋅。在過去，鋁因為容易被腐蝕的問題，並未被採納，若鹼性電池真的能以鋁為材料，那麼重量有機會比鋰電池還要輕，也會比當前市面上的鹼性電池還要便宜。

報導稱，Ionic計畫在週四於永續能源研究機構Rocky Mountain Institute舉行的35週年大會上，宣布研究成果。

鹼性電池若能重複充電、將有諸多好處，但鋰電池之父John Goodenough也不是省油的燈。Goodenough雖已高齡94歲，卻寶刀未老，他今（2017）年3月已經帶領德州大學（University of Texas）奧斯汀分校團隊，打造出「全固態」（all-solid-state）鋰電池，不但更加安全，容量還是三倍大，而且只要數分鐘就可充電完畢，不必再像從前那樣等待數小時。

Apple Insider、CNET、CleanTechnica等多家外電3月6日報導，Goodenough採用全新技術打造的鋰電池可適用幾乎所有裝置，包括iPhone、MacBook Pro、車用電池或是類似特斯拉「Powerwall」家用電力儲存系統等，都可使用這種電池。

Goodenough團隊開發的最新技術，使用了玻璃製的電解質（不是以往的液體 ），可解決電池充電過快時激發「金屬鬚晶」（metal whiskers），導致正負兩極相互接觸、繼而起火爆炸的問題。

玻璃電解質是以鋰、鈉或鉀製成，可大幅增加電池的能量密度，據研究人員估算，即使充放電超過1,200次，電池續航力也幾乎不受影響。不僅如此，即使環境急凍到零下20度C，新款電池依舊能正常運作。

研發團隊指出，玻璃電解質可簡化電池製造流程，採用的材料也都對環境友善，能輕鬆回收再利用，另外更能降低稀土金屬的使用量。不過，德州大學科技商業化辦公室目前還在跟多家電池大廠洽談授權事宜，因此短期內恐怕還無法上市。

（本文內容由授權使用。圖片出處：Ionic Materials）  

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象