GOV 網站大多數都是開普承擔。

@megamilk 我用了 3 個月餓了麼，實在無法忍受這平台，已轉美團很久了。餓了麼也卸了。
@tedcon 建議你也別洗地了，單在 V2EX 這個帖子裡，已經有那麼多人對你們有意見，你覺得市場外面的滿意度是怎樣？客滿就是客戶滿意度部門吧？我覺得最終年終會議，他們肯定把滿意率“做”到很高。等他們真正解決問題？呵呵

我試過幾次等了 2 個多小時最後換來一個系統取消訂單！！！
也試過騎手提前點送達！！！
更加試過寫著騎手專送最後變成了外包配送或者店鋪配送，等的那個時間真是餓到不餓了！！！
對了，還有你們的 UI，提過幾次 bug，但是你們客服基本不理，只是問句是點不了餐嗎？

這麼說吧，
如果你直接修改提交的內容，但是 signature 不改，微信那邊驗簽的時候直接就不通過了，因為你需要用被修改的數據重新跑一次加密的過程，才能得出正確的 signature （微信也是用得到的數據根據相同的公式進行簽名，再對比簽名是否一致）
為什麼需要隨機字符和時間截加進去，就是為了進行數據混餚，增加解密難度（解出 appsecret 的難度）。


後期為何綁定 IP，
那是因為太多人的 appid 和 appsecret 洩露出去了。

@leiuu
微信驗證方式：
比如提交數據是：
name="abc"
age = 18

假設 appid : 12345678
假設 appsecret: abcdefg

此時根據時間生成一個 timeStamp = 123456789
隨機生成一串字符：nonseStr = a456sdf

簽名方法：
根據排序，文本合併：
signature = md5('age=18&appid=12345678&name=abc&noseStr=a456sdf'.abcdefg)//大致這樣吧具體忘記了

然後可以得出，
如果篡改上面任意一個參數，最終的 signature 內容是不符的。
上面條件，只有 age,name,timeStamp,nonseStr 是別人知道的，缺少了 appid 和 appsecret 兩個參數，
因為 timeStamp 是一直變的，nonseStr 也是隨機生成的，如果通過截包方式猜測 appid 和 appsecret 明顯困難。（當然不排除有人直接固定 timestamp 和 nonseStr 的內容）
所以就算 signature 或者 每次的請求被人攔截了，想篡改數據可能不大。

為什麼後面微信會有個白名單驗證呢。
那是因為有很多開發者把 appid 和 appsecret 都丟上 github 去了。
所以後面開通的公眾號獲取 accessToken 都要設置 IP 白名單。

ememe，沒什麼好扯的， @l4ever 所說沒大問題，安全事項肯定要注意。
我想表達的是你參考微信，當初 oauth 就可為何後面加入百名單。
按時間計算 5s 内的时间戳有效 這個方式有個平台在用，他們的技術給人罵到不敢吭聲。（你想象下網絡的延遲和時間的不同步問題因素），後來他們技術改為時間不一致後返回相差時間。（不用想了，又被人噴了一次，既然你都返回相差時間，你 TM 還不如直接跳過這個驗證？）

如有可能 IP 白名單即可了。不用那麼多花花綠綠的。

具體不是很清楚，不過看你香港節點，速度去到 11MB/S，你究竟是什麼人，國際帶寬過 100M，要不你建個梯子，我們大家一起幫你測試下

@l4ever appid appsecret 洩露出來，現在好像也沒什麼危害了吧...
微信 JSSDK 或 Oauth 現在需要自行配置業務域名和 IP 白名單。

這麼說吧，
假設你的瀏覽器高度寬度固定值是 800 *600 像素
那麼你去到 2K，4K 屏幕也好，你的像素永遠是 800*600
然後根據相對的尺寸（瀏覽器內文距離頂部 X 截圖到瀏覽器內文距離右邊的 Y ）截圖
出來的結果就不會受到你電腦的分辨率影響。

可是你可以用相對坐標獲取吧？
selenuim 真的不熟悉，
如果是 electron 的話，直接 set 絕對的寬高（像素），
然後通過 set 好了的寬高像素進行相對定位。
那樣無論去到什麼屏幕你提取出來的都一樣。

@NGPONG 我也不是一個扎實的前端，只是有段時間因為某些原因所以接觸過。
我當時遇到的問題和你現在的問題差不多，但我們需求不一致。
媒體查詢：根據不同分辨率設備設置不同的樣式。等於一個網頁根據不同分辨率就寫一次，具體些多少次要看你適配的精度。適配精度越高，寫的 CSS 越多。
“具体点来说的话就是我做的是 OCR，截取当前浏览器所显示的内容（截取功能由 selenuim 提供出来）并在相应的坐标读取一些内容。”
大致明白你要做什麼，類似腳本的外掛對屏幕定位讀取血條計算百分比是否需要吃紅 吧？
selenuim 說實話不熟悉，不清楚你實際需求，但根據你所說的，會不會用 electron 寫，注入 JS 進行定位你需要的目標 dom，然後提取出來進行 OCR 識別會方便一點呢？

@NGPONG 好的，其實問題的核心應該是 物理尺寸 和 屏幕像素 的轉換關係吧？
你沒說是用什麼寫的，我權當 css 吧，
在不同分辨率下，顯示效果的物理尺寸相同，實現的方式只能靠百分比進行了，(當然，你獲取屏幕 dpi 和分辨率後進行換算，其實和百分比實現的方式是一樣的)。但是文字等比放大的問題你怎麼處理？而且這樣設計出來的界面會很彆扭，為什麼彆扭？因為你的素材肯定要選個固定像素的吧？我當你選擇 2K 的素材，那麼去到 4K 的時候，你的素材是進行了等比放大，換句話說就是毛孔都出來了，另外還要考慮寬屏和正屏的問題。然後你會想那我就直接用 4k 作為素材，此時如果用戶是 800*800 的屏，那你上面的文字是縮小到有多小啊？
我不知道你是用什麼設計界面，
但是在 css 裡有個媒體查詢，根據不同的分辨率進行不同的匹配。
偷懶點的做法還可以設定一個像素固定值，屏幕大的兩邊空，小過固定值的就滾動，保持用戶看到的就是設計者當初設計的模樣。

nginx 是 reload 和 start 時候把配置引用到內存裡的，並不是有訪問才讀取磁盤裡的配置文件。
所以你分多個配置和一個大的配置文件，對於後續的請求操作，是沒有影響的。

但是你說到 5000 個站點，請問都是靜態嗎？還是動態？還是你這個 nginx 只是做負載？
排除負載和動態，你確定你的服務器能支撐到嗎？

1、肉眼看上去一樣。
CSS 不是有個百分比嗎？

另外你的提問已經有問題了，
一開始需要不同分辨率裡面顯示的實際效果高寬是一樣的，
後面的需要就變成了無論如何大小不變。

在不同分辨率實際顯示效果高寬一致的情況下，他只能根據比例進行等比縮放，進行縮放後的尺寸肯定變大 /小了。

可以
親，這邊建議您可以收購了他們的股份，然後已最大股東的名義命令他們把 1 個 IP 轉給你。

--------------------------------------------------------------------------------------------------------------
上面說笑的，不過說真的；
嫌国内的 vps 厂商提供的配置不够，自己的电脑配置很高。
為什麼不選擇主機託管服務？

或者說向運營商申請固定 IP ？
如果需要 BGP 我記得最少需要在 3 家不同運營商申請了 IP 後才可申請 AS 號

@18510047382
可能大家遇到的需求並不相同，或者並不在同一個頻道對答。
老實說我關注的只是數據交換這一塊，你可以看回我之前的回復，都是基於這一塊出發的。
另你所說的字符入庫，的確是可以這麼幹，而且這麼幹絕對能把 DBA 干死。
最後，我沒有任何不支持“新”事物的觀點，也知道並非所有新東西一發生周圍市場就能豐富起來。
但我覺得最直觀的就是
1、我為什麼要把 JSON 換成 PJSON ；
2、我換成 PJSON 後我是能縮短或增便了什麼；
3、我把現成項目改用 PJSON 後需要多少時間；

我不是專門和你缸，看了你回復別人的信息也大概清楚。（#44 手误写成了数据交换格式，实际上是数据格式，不好意思。（另外我也不是这种 “回复每楼说你不懂其实我的东西很牛逼” 的人，只是这里键盘侠太多了，我十分反感这种人，但是你正常提意见还是没有问题的））

你所說的“这里键盘侠太多了，我十分反感这种人”，裡面應該包含我吧。
我不知道是因為我的提問字眼太尖銳了讓你難入耳還是怎樣，
真心希望你能把我回復從頭看一次，我的著重點是“數據交換”，我看完你所有介紹及回復你都沒說到交換時候如何便捷或特點。

@18510047382
我现在都不知道你到底在问什么，pjson 解析器能把 pjson 的特殊语法转换成纯 js 对象，pjson 主要就是针对配置文件使用的，pjson 就是给.json 文件提供一些例如注释之类的功能。pjson 文件传输的时候只需要传输 pjson 字符串就行了啊，然后你在接收端使用 pjson.parse 解析，这也有问题？另外我觉得我已经和你说的够多了，再有问题我也不会回复了。

你是覺得數據交換就是用 NODE.JS 讀取個配置嗎？
你權當我不懂你們前端的思維。
數據來源要麼是手動寫死，要麼是數據庫取值，
排除手動寫死的，哪個數據庫支持 PJSON 格式？是需要轉換成 JSON 入庫嗎？
簡單的數據傳輸：
後端->前端
使用 JSON 前：
把後端的對象或數組轉換成 JSON 傳輸 給前端，前端直接解析就成了前端的對象 /數組。大家圖個方便。

換成 PJSON 後：
後端：到處找對應語言的解析庫，發現沒有，然後口中念念叨叨地不知道說著什麼邊模仿著 JS 源碼來處理。
前端：找到庫了，在每個使用的地方加載下再使用再解析傳回來的 JS。
運維：看著傳輸中數據的注釋和未經計算的固定數字公式陷入了沉思，無奈地看下監控中的 Netflow 和顯示器下面擺放著領導給的帶寬使用情況，不禁地思考起來，前端的輪子永遠都是那麼樸實無華，且鼓譟。

最後，回不回復是您的權利，不過看了下你 github 上的所有輪子，裡面 issue 都是空白的，不回復我您不覺得空虛無聊冷嗎？

@imdong Node.js 的配置文件是手寫的。

@18510047382
說真的，我們大家看完一大堆東西，
都不知道究竟用這個替換成 JSON 後能減輕或幫助到我們什麼東西，
這個點我覺得你應該說說比較好。

另外我不知道別人為什麼用 JSON，
我知道的就是我自己為什麼用 JSON。

就如上面所說，
因為 PHP 直接用 JSON_ENCODE(array|object)它就返回了 JSON
JS 只要是 ajax 設置了 JSON 類型就自動解析出 JS 對象。
換成.NET,JAVA 也是如此，只是它們需要加載第三方包。

然後傳輸中的對象就像你所說的，它們屬於 string 類型。那請問 PJSON 傳輸時候是否也是 STRING 類型呢？

@18510047382
引用自百度出來的：
们要把需要计算的数字乘以 10 的 n 次幂，换算成计算机能够精确识别的整数，然后再除以 10 的 n 次幂，大部分编程语言都是这样处理精度差异的，我们就借用过来处理一下 JS 中的浮点数精度误差。