维权的核心是：二不要、一要

1. 不要为难客服，他们的工作是安抚消费者情绪，他们可能会同情你的遭遇，但他们没有权利做出任何决策；
2. 不要胡言乱语、撒泼耍赖、得理不饶人；
3. 要相信党和政府，他们是站在群众的一边，而且他们有能力抗衡企业。

完整事件

起因

本人于2022年6月于京东自营平台购买了一款家用电器，并按照要求安装平稳使用三年，于 2025 年 8 月，刚出三年保修期，突然因固定装置发生故障差点导致家中老人和孩子受伤，所幸并无大碍。

第一次交锋：和店铺客服反映情况，店铺客服给到免费邮寄固定装置，并发放故障配件折扣券。
第二次交锋：和平台客服反映情况，后平台客服给到免费邮寄固定装置和故障配件，并由平台承担安装费用。

在这个过程中平台其实已经帮了大忙，我对他们心存感激，然而我忧心的并不是电器能否修好，而是他未来如果又发生故障，但如果导致家人受到伤害怎么办。所以我开始了自己的维权路程。

维权路程

1. 通过 国家企业信用信息公示系统 该京东自营网店属于企业直营，确定了投诉目标。
2. 通过 12315 平台向该企业所属的市场监督局，投诉并举报：
   1. 投诉：伸张自己所求 - 根据消费者权益保护法中 第十八条“经营者应当保证其提供的 商品或者服务符合保障人身、财产安全的要求。 要求企业退一赔三。
   2. 举报：举报企业违法行为 - 因该企业所生产电器不符合保障人身安全要求的基本原则，要求市场监督局责令该企业对该批次电器进行召回，并检查市面现有电器的安全性。

到此实际已经完成了所有维权，在和市场监督局工作人员的三次电话沟通中，他对我的遭遇表示同情，并表示一定会给到结果。

结局

经过市场监督局的努力，企业客服来电答应退货退款，我要求三倍赔款其实并不抱有能够实现的希望，我只是希望我家人不再受到伤害，于是答应了。

同时市场监督局会继续监督该企业的产品，杜绝此类伤人事故的可能。

插曲1 - 起诉书

你们也知道，12315 只能协商，所有我还是使用 AI 准备了一份起诉书，如果企业负隅顽抗调解不成，我会不客气直接在当地法院起诉。必须说 AI 现在完成此类稿件真的好用，整个起诉书由四个章节构成，是标准的起诉书模板，我仅引用一下第四章节原告的诉讼请求依据：

四、原告的诉讼请求依据
1.退一赔三的合理性：根据《消费者权益保护法》第五十五条第一款“经营者提供商品或者服务有欺诈行为的，应当按照消费者的要求增加赔偿其受到的损失，增加赔偿的金额为消费者购买商品的价款或者接受服务的费用的三倍；增加赔偿的金额不足五百元的，为五百元”，虽本案被告可能不存在主观欺诈，但涉案电器因设计缺陷导致安全隐患，属于“不符合保障人身安全要求”的根本性质量问题，且被告在销售时未对潜在风险作出警示，原告基于对品牌及产品质量的合理信赖购买使用，现因电器故障面临持续的人身安全威胁，有权要求被告退还货款并支付惩罚性赔偿（三倍价款）。
2.召回产品的必要性：涉案电器的同批次产品可能存在相同设计或工艺缺陷（社交媒体反馈已佐证），若不及时召回并改进，将导致更多消费者面临类似风险。根据《消费者权益保护法》第十九条“经营者发现其提供的商品或者服务存在缺陷，有危及人身、财产安全危险的，应当立即向有关行政部门报告和告知消费者，并采取停止销售、警示、召回、无害化处理、销毁、停止生产或者服务等措施”，被告作为生产者和销售者，负有主动召回缺陷产品的法定义务。

我觉得这才是使用 AI 的正路，让普通人也可以攥写出专业的文稿。

总结 - 普通人维权感想心路

社会上，每个人都有自己的立场，从电商和平台的角度来说，如何将损失降到最低是他们的立场，从消费者角度上来说，买到一个商品，并且在合理的使用期限内安全地使用自己买到的产品是自己的立场。

这个电器如果只是普通的故障，不会伤害到人，我可能就自己修了，我在小红书上也确实是个装修翻车博主，各种奇怪的故障都遇见过，出事后我也迷茫了一阵不知道自己该要什么，之前的故障都不像这次这样让我害怕，这也是我一定要退货的原因，尽管它已经过了三年的保修期，但它还没达到它的合理使用期限。

立场的冲突是很常见的，你不能因为自己占理就要求放弃对方的立场，那样只会沾一脸土回家。我认为正确的方式是找一个权限更高的调停者，也就是国家的各种机构，通过向他们反映情况来完成自己的合理诉求。

有的人可能认为国家也未必和自己站在一边的，我觉得国家只和合理的诉求是站在一边的，如果你的诉求是合理合法的，尤其是可能影响到大多数人切身利益的，国家为什么不支持你呢。

社会始终是一个个普通人构成的，你的遭遇，说不定有一天就落在别人身上。

趁着国补入手了 Mac mini M4，因为家里内网接入了 2.5G 交换机，所以顺手升级购入了万兆以太网卡的版本。不过没想到问题才刚刚开始。

入手了 Mac mini M4 非常开心，迫不及待地把开发环境配置上去，这次打算把 Git 仓库放在 SMB 共享文件夹里，这样多个设备都能对同一个代码仓库进行修改。不过几次 clone 仓库时发现有问题，会出 SIGBUS 错误，搜索了一下这个问题普遍就在把 Git 仓库放在 SMB 共享文件夹，然后就没有然后了。

再往下查，先是发现从 NAS 复制大文件时会突然中断，继而发现网卡有时会自动丢失连接，表现是 System Settings 里的 Ethernet 会从绿灯变成红灯。我心想不妙，不会碰到新网卡和交换机不兼容了吧，都要准备退货了。。。

当时开着 ping 路由器，隔一段时间会丢失连接。

64 bytes from 192.168.88.1: icmp_seq=4225 ttl=64 time=0.966 ms64 bytes from 192.168.88.1: icmp_seq=4226 ttl=64 time=0.979 ms64 bytes from 192.168.88.1: icmp_seq=4227 ttl=64 time=0.955 msping: sendto: No route to hostRequest timeout for icmp_seq 4228ping: sendto: No route to hostRequest timeout for icmp_seq 4229ping: sendto: No route to hostRequest timeout for icmp_seq 4230ping: sendto: No route to hostRequest timeout for icmp_seq 4231ping: sendto: No route to hostRequest timeout for icmp_seq 4232Request timeout for icmp_seq 423364 bytes from 192.168.88.1: icmp_seq=4234 ttl=64 time=0.905 ms64 bytes from 192.168.88.1: icmp_seq=4235 ttl=64 time=0.821 ms

但我也想苹果应该不至于连个万兆网卡的 2.5G 兼容都做不好吧，如果标准没问题，那只有私货有问题了，苹果一向喜欢搞私有协议的。

看了一下 System Settings 的 Ethernet 里有个 AVB/EAV Mode，默认情况下开启，搜索了一下它是什么：

Audio Video Bridging (AVB) mode is a set of technical standards that improve the reliability, synchronization, and low latency of switched Ethernet networks. AVB defines the features, options, and configurations needed to build networks that can transport time-sensitive audio and video data streams.

EAV may refer to Ethernet Audio/Video Bridging, a standard that allows audio and video signals to be sent over an Ethernet line. The IEEE is developing the EAV standard, which includes features like bandwidth reservation and time-synchronized low latency streaming services. When deployed, EAV will allow audio and video hardware to be connected via Ethernet, enabling the simultaneous transmission of network, audio, and video signals.

我想这可能就是私货了，因为如果使用 USB 网卡是没有这个选项的。将网卡 Hardware 切到 Manually 模式，取消掉它的复选框。运行了一阵，搞定～

Apple Community 里也找到了类似的问题 - https://discussions.apple.com/thread/255876126?sortBy=rank

说实话我希望苹果不要默认开启一些大多数人用不到的东西，而是默认关闭它，如果真的有人有需要，再自己手工开启。

安装这些命令行工具的常规做法是使用 Brew，但在今年9月份的一次更新中，Brew 放弃了对 Monterey 的支持，如果强行安装使用它，软件包不会直接安装 bottle 二进制而是从源代码开始安装，同时会报出下面几行字：

Warning: You are using macOS 12.
We (and Apple) do not provide support for this old version.
It is expected behaviour that some formulae will fail to build in this old version.
It is expected behaviour that Homebrew will be buggy and slow.
Do not create any issues about this on Homebrew’s GitHub repositories.
Do not create any issues even if you think this message is unrelated.
Any opened issues will be immediately closed without response.
Do not ask for help from Homebrew or its maintainers on social media.
You may ask for help in Homebrew’s discussions but are unlikely to receive a response.
Try to figure out the problem yourself and submit a fix as a pull request.
We will review it but may or may not accept it.

非常不幸的是，通过 Brew 走源代码安装的 Qemu 截稿最新的 9.1.1 在 Monterey 上可以通过编译，但通不过单元检测，于是一直无法顺利安装。期间我尝试使用 macPorts，但它安装 Qemu 通过 Colima 启动时有一个参数不对，导致串行日志没有内核启动内容，这意味着启动失败了；也想尝试另一个 Fink，但它居然连 Catalina 的支持都未完成。所以我开始了对 Brew 的研究，这里记录一下结果。

资料来源于 Github 上 “macOS 12 unsupported? #5603” 的这条回复 - https://github.com/orgs/Homebrew/discussions/5603#discussioncomment-11253847

核心点有：

1. Brew 虽然停止了对 Monterey 的支持，但是针对老系统的 bottle 并未删除，只是不再在老系统上构建新版本的软件包。
2. 这里依然使用 Bottle 安装，原因是我们只需要使用到软件包，而不想安装编译所需的依赖。
3. Bottle 都是老版本的，我们无法在老系统上使用新版本软件包的 Bottle。

操作方法

这里以 Qemu 为例。

找到对应软件包的 Formula 和对应提交哈希

Qemu - https://github.com/Homebrew/homebrew-core/blob/master/Formula/q/qemu.rb

点击右上角 History，翻找它的提交历史，找到 Monterey 的 bottle 依然被保留时的提交哈希。

Qemu - https://github.com/Homebrew/homebrew-core/commit/a30892887bd5ee16db1ecf3094951734e5e4dfe4

这时可见它的提交哈希是 a308928

进入 Homebrew 切换到该提交哈希

cd $(brew --repository)/Library/Taps/homebrew/homebrew-core/git checkout -b qemu-freeze a308928

这里没有使用原文的 macOS-monterey-freeze 分支名称，是因为原文后面一段使用了相同的分支名，会出冲突。同时因为不同的软件包的哈希值可能是不一样的，其实根据需要安装的软件包起分支名称会更加合适一点。

不过 Qemu 对应的 a308928 提交于2024年9月10日，刚好在 Brew 放弃对 Monterey 支持之前，我自己测试它已经足够应对在 Monterey 上安装老版本软件包的需要了 – 比如切到 Colima 的提交哈希时，它还会从源代码构建部分依赖，但用 Qemu 那个分支就不会。我自己打算锁定这个提交的时间了。

然后使用 brew install 安装需要的软件包，就会发现它不会再安装最新版本，而是安装老版本的 Bottle 了。

brew install qemu # It will install 9.1.0 from bottle, not the 9.1.1 from source

锁定 Brew 让它不再自动更新 Formula

在设置环境变量的启动脚本中，增加一个：

    export HOMEBREW_NO_AUTO_UPDATE=1

例如我使用的 zsh 就修改 ~/.zprofile 增加上面这一行。
Homebrew 的安装脚本就永远不会更新了。

一点心得

Brew 作为 macOS 上最受欢迎的软件包安装工具，还是有它的设计想法在的，虽然它不直接支持安装旧版本的软件包，但可以通过切换 Formula 所在的 Git 仓库的 commit 安装旧版本的软件包。

我不太能说这是个好主意，但也给了个可以回滚的办法。

前一阵看了一下 powershell 给我了我一些启发，原来管道之间还可以传对象，让后续的数据处理更加简单方便。

所以我打算将我的命令行系统现代化一下，抛弃一些历史悠久的东西，诚然这会有额外的学习成本，不过持续学习是程序员的基本素质了。

Shell - nushell

Powershell 虽好，但是它启动得太慢了，无意间我发现了 nushell，这熟悉的面向对象的管道、结构化的数据存储和传输、二十毫秒左右的启动速度，简直不要太棒了。

具体安装流程什么的看官网吧，我只贴一下我首次安装后的配置流程。安装后执行 nu 命令就可以进入 nushell。

我只使用 nushell 自己的配置能力，所以看着会有点绕。但好处是不受配置文件路径配置不同的影响，可以照抄。

1. 配置默认编辑器

nushell 自己的配置能力需要 $env.config.buffer_editor 获取编辑器，它的默认值是 null 意味着当你直接执行 config env 的时候它会报错：

Error:   × No editor configured   ╭─[entry #18:1:1] 1 │ config env   · ─────┬────   ·      ╰── Please specify one via `$env.config.buffer_editor` or `$env.EDITOR`/`$env.VISUAL`   ╰────  help: Nushell's config file can be found with the command: $nu.config-path. For more help: (https://nushell.sh/book/configuration.html#configurations-with-built-        in-commands)

所以这里需要手工改一下，$env 的具体说明请参考官方文档。

$env.config.buffer_editor = vim  # 这里暂时修改为 vim，也可以选择自己称手的编辑器

将默认编辑器配置持久化

执行 config nu 打开 nushell 的配置文件，并找到 buffer_editor 这行，将原来的 null 改为自己的编辑器

    buffer_editor: vim # command that will be used to edit the current line buffer with ctrl+o, if unset fallback to $env.EDITOR and $env.VISUAL

2. 还原环境变量

需要特别说明的是 nushell 的环境变量和 POSIX Shell 差异巨大，它是结构化的存储，如果使用 echo $PATH 会报错告诉你根本不支持：

Error: nu::parser::env_var_not_var  × Use $env.PATH instead of $PATH.   ╭─[entry #6:1:6] 1 │ echo $PATH   ·      ──┬──   ·        ╰── use $env.PATH instead of $PATH   ╰────

要访问环境变量直接使用 $env.[ENVIRONMENT_VARIABLE] 即可。上一章节中的 config 也是以环境变量存储，但是是一个嵌套的对象。 -- 这才是我想要的命令行环境。

$PATH

nushell 的 $PATH 默认只有 /usr/bin 和 /bin 两个，对于装了 brew 的我来说是不可接受的。

首先要在原来的 Shell 中通过 echo $PATH 获取原来的环境变量，我这里是：

/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/opt/homebrew/sbin:/usr/local/sbin:/usr/sbin:/sbin

而在 nushell 中 $env.PATH 是这样的：

╭───┬────────────────────╮│ 0 │ /usr/bin           ││ 1 │ /bin               │╰───┴────────────────────╯

其实我没有找到 nushell 的 PATH 在哪里初始化，但是按照官方文档 的说明，目前 nushell 中的路径在整个路径列表中是在中间的，这也就意味着需要在前面添几个，后面添几个才可以。

执行 config env，进入环境变量编辑界面，找到 $env.PATH 段，改成下面这样，prepend 表示在数组前面添加路径，append 表示在后面添加路径：

# To add entries to PATH (on Windows you might use Path), you can use the following pattern:# $env.PATH = ($env.PATH | split row (char esep) | prepend '/some/path')# An alternate way to add entries to $env.PATH is to use the custom command `path add`# which is built into the nushell stdlib:# use std "path add"# $env.PATH = ($env.PATH | split row (char esep))# path add /some/path# path add ($env.CARGO_HOME | path join "bin")# path add ($env.HOME | path join ".local" "bin")# $env.PATH = ($env.PATH | uniq)    $env.PATH = (   $env.PATH |  prepend /usr/local/bin |  prepend /opt/homebrew/bin |  append /opt/homebrew/sbin |  append /usr/local/sbin |  append /usr/sbin |  append /sbin) 

保存后，重启 nushell，再执行 $env.PATH 就会输出成这样，即为正常 ，通过 brew 安装的所有命令行工具就回来了：

╭───┬────────────────────╮│ 0 │ /opt/homebrew/bin  ││ 1 │ /usr/local/bin     ││ 2 │ /usr/bin           ││ 3 │ /bin               ││ 4 │ /opt/homebrew/sbin ││ 5 │ /usr/local/sbin    ││ 6 │ /usr/sbin          ││ 7 │ /sbin              │╰───┴────────────────────╯

其他资料

1. 推荐从别的 Bash 迁移过来的参考一下，方便理解它的概念和差异 -Coming from Bash
2. nushell 的第三方扩展 - nu_scripts，有一个 nupm 项目貌似可以用来下载安装，我还在测试中。

编辑器 - Micro

其实绝大多数情况下我们在命令行下只需要一个简单的文本编辑工具，传统的编辑器学习成本太高了，vim、emacs 只留如果不看文档进入后都不知道该如何退出来，即使是足够简化的 nano 也需要重新学习。所以我换成 micro 了，快捷键和 GUI 下的编辑器基本相同：

1. 关闭 Ctrl + Q
2. 保存 Ctrl + S
3. 查找 Ctrl + F
4. 撤销 Ctrl + Z

更多请参考官方的 keybindings.md。另外，它还有一些不错的插件。

编辑器 - Helix

vim 的最大问题是在于它本身过于简单，但如果要让它能用起来还得加上一堆插件。Helix 就比较简单了，基本开箱即用。

TODO: 这个我还得多用用再来写。

Github Copilot 确实好用，不过作为程序员能自己动手，就尽量不使用商业软件。

Ollama 作为一个在本地运行各类 AI 模型的简单工具，将门槛拉到了一个人人都能在电脑上运行 AI 模型的程度，不过运行它最好有 Nvidia 的显卡或者苹果 M 系列处理器的笔记本。

我自己是在 Macbook Pro M1 Pro 32G 统一内存的笔记本上运行的，目前运行 codellama:7b-code-q4_K_M 小模型效果都不错，但是运行模型体积稍大一点就容易出现反应迟钝（例如 dolphin-mixtral:8x7b），或者输出出错的情况（例如 codellama:34b-code-q4_K_M)。我的意思是，本地运行 AI 还是要量力而行，即使对自己的硬件有信心，也建议从小慢慢往大了测试。

本地运行 Ollama

下载安装 Ollama

直接从 https://ollama.com/download 官网下载应用即可，目前平台覆盖比较齐全。

下载后安装，命令行中会增加 ollama 命令，启动后会在系统托盘中出现羊驼图标。

下载模型

我这里依然以 codellama:7b-code-q4_K_M 它是针对编码训练的 Lama 模型，对大部分代码有比较不错的兼容性。

直接在命令行中运行：

ollama pull codellama:7b-code-q4_K_M

然后就会开始下载，在 4G 多。下载完成后可以先启动试试：

ollama run codellama:7b-code-q4_K_M

它会跟你一个 >>> 的命令提示符，然后就可以和它沟通了，一定要描述清晰你的需求，否则就会输出一堆没什么用的东西。:-(

使用 Continue 与 IDE 集成

VSCode 的 Llama 插件目前我觉得 Continue 还算不错，它也提供了 Jetbran 的插件。

截稿时它的自动补齐功能还在 pre-prelease 版本中，所以我这里以它正式版本为主。

安装 Continue 插件

直接从 Extension Marketplace 安装即可 https://marketplace.visualstudio.com/items?itemName=Continue.continue

安装完成后在 VSCode 左侧侧栏中会增加一个 > CD_ 的图标，这就是它的主界面了。

配置本地 AI 模型

Continue 默认只提供了几种线上 AI 模型的试用，如果需要更改，需要在 Continue 主界面中点击右下角的齿轮图标，进入配置界面，会打开 $HOME/.continue/config.json，需要在该文件的字段中增加以下字段：

{  "models: {    {      "title": "Local Ollama",      "provider": "ollama",      "model": "codellama:7b-code-q4_K_M"    },    // ...  }  // ...}

这样就启用了本地 Ollama，如果未来需要更换别的模型，直接修改 model 字段即可。

使用 Continue 进行 AI 辅助代码编写。

Continue 主要有两种使用方式：

1. ⌘ + L 选中代码

选中需要的代码，按下 ⌘+L 快捷键后，Continue 界面就会弹出来，并将选中的代码插入到聊天框中，这时候你可以让它帮你编写单元测试，或者检查可能存在的 bug。

2. ⌘ + I 插入代码

在代码的任意位置按下 ⌘ + I，会弹出一个小的 prompt 输入框，你可以输入需求让它快速生成。

总结

相对线上的大模型，本地运行的小模型在精准度上还是有些欠缺，不过已经可以代替部分工作，最主要是它依托开源的优势，降低了成本。

Copilot 的免费替代

如果觉得本地 Codellama 模型不够使用，其实还有个 Copilot 的免费替代 - https://codeium.com/ 这个功能我自己试用下来也很不错，目前跟本地 Ollama 交替使用。

现在很流行将本地开发环境放到远端，我也这么做很久了，因为服务器的强大硬件效率比本地开发要高得多，但调试工作放在本地电脑上，而且每次开启 IDE 都有个重新加载的过程，所以在想能不能把整个开发调试环境全都放在服务器上呢，这样不管去哪里，打开远程桌面就可以直接进行工作。

这里使用远程桌面服务的目标是进行远程开发或者测试，不推荐在提供对外服务的服务器上安装，可能对性能和安全性造成影响。

远程服务器如果有了图形界面，就可以安装顺手的 VSCode 编辑器进行远程开发，本地电脑就作为一个瘦客户端，对配置要求可以非常低。我之前曾经考虑过换成 Windows 的远程开发机，但是 NTFS 羸弱的小文件处理性能让我打消了这个想法，做开发而已，要求不高。

先来看一下总体效果，macOS 使用微软的远程桌面连接到了 Linux 服务器上。

那么下面就开始吧。

背景介绍：

远程桌面协议有很多种，例如常见的 VNC、TeamView 之类的，XWindow 本身也支持将本地的显示通过 DISPLAY 环境变量重定向到另外台电脑上显示。

不过我这里用的是微软的 RDP 协议，它的虚拟虚拟显示器分辨率可以由客户端指定，体验相对较好。

而它在 Linux 上通过 xrdp 服务将 XWindow 协议转换为 RDP 协议供客户端调用。

准备工作

在开始之前建议先使用 adduser 命令建立一个跟自己 git 同名的普通账号，这样在操作代码资源时更加方便，普通账号权限受限也相对更加安全，如需进行越权操作，可以给他添加 sudo 操作权限。

本文假设你已经具备基本的 Linux 知识水平，所以所有内容如果碰到问题请先自行查阅资料。

安装

以 CentOS 8 版本为例，按照下面命令一次输入即可：

sudo dnf install -y xrdp # 安装 xrdp 服务sudo systemctl enable xrdp # 启用 xrdp 服务sudo systemctl start xrdp # 启动 xrdp 服务

安装 XFce 桌面环境

桌面环境有很多种，红帽系默认是 GNOME，但它的半透明和阴影较多不适合在远程桌面上使用，所以我用了 XFce 一个轻量化的桌面环境

sudo dnf install -y @xfce-desktop # 安装 xfce4-desktop 分组echo "xfce4-session" > ~/.Xclients # 将 xfce4 作为默认桌面环境chmod a+x ~/.Xclients

其他分组可以使用下面命令查看：

sudo dnf grouplist -v

如果有别的桌面环境喜好，也可以手工安装，修改 ~/.Xclients 即可启动。

连接远程桌面环境

安装远程桌面客户端 App

• Windows: https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-allow-access
• macOS: https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-mac （其中提到的 下载链接 需要外服 AppStore 账号）

连接

启动客户端，点击 + 号新增 PC：

填入用户名和密码，点击 Continue 正常情况即可连接：

声音转发

一般情况下，没有声音的远程桌面已经足够使用了，不过如果有更高要求，可以考虑把远程开发机上的声音也同步过来，这就要提到 xrdp 相对别的远程桌面协议强大的地方了，它是能通过一个插件支持声音重定向的。

安装依赖

正常情况下开发着工具应该是都已经安装好了，可以再次执行一下确保环境正常

sudo dnf groupinstall "Development Tools" -ysudo dnf install rpmdevtools yum-utils -ysudo rpmdev-setuptree

安装开发所使用到的库和头文件，这里其实用了 PulseAudio 它也是目前 Linux 上的混音器的事实标准，我们这里需要通过它的一个插件将声音通过远程桌面重定向过来。

sudo yum install pulseaudio pulseaudio-libs pulseaudio-libs-devel -ysudo yum-builddep pulseaudio -y 

【可选】建立独立的编译账号

主账号安装 brew 后可能一些共享目标（so）和头文件等开发运行时可能会乱，所以这里可以考虑建一个纯粹的 Linux 编译账号，只使用原始的环境进行编译

推荐建立这么一个账号，这样以后有别的编译任务的时候也可以使用它。

sudo useradd mockbuildsudo usermod -G mockbuild mockbuild

然后切换过去

sudo su - mockbuild

准备编译所依赖的 PulseAudio

yumdownloader --source pulseaudiorpm --install pulseaudio*.src.rpm

然后就会看见你的用户目录下多了 ~/rpmbuild/BUILD/ 目录，刚刚装的 rpm 源代码就在里面，可以直接用下面命令进行编译。

rpmbuild -bb --noclean ~/rpmbuild/SPECS/pulseaudio.spec

【主角】编译和安装 PulseAudio 的 XRDP 插件

git clone https://github.com/neutrinolabs/pulseaudio-module-xrdp.gitcd pulseaudio-module-xrdp./bootstrap && ./configure PULSE_DIR=~/rpmbuild/BUILD/pulseaudio-*makesudo make install

验证安装

使用 pulseaudio -D 启动音频服务后，如果之前已经启动过，那可以用 pulseaudio -k 重启服务，应该就能从音频控制面板中调节音量了，如下图：

Trouble Shooting

服务无法连接

首先使用下面命令检查 xrdp 服务是否正常运行中
sudo systemctl status xrdp

其次检查防火墙（一般是关掉的，但不保证部分人可能开着）

firewall-cmd --permanent --add-port=3389/tcpfirewall-cmd --reload

连接后闪退

一般是桌面环境没有安装成功，可以先用下面命令看一下服务日志确定一下：

sudo cat /var/log/xrdp-sesman.log

报告用户名或者密码错

xrdp 使用的是 DevCloud 上的本地用户名和密码，需要使用能直接登录的用户名和密码登录。

以之前碰到过的 CSS 值展开代码为例，它的输入是个不定长，以空格作为分割的字符串，输出的是一个长度为 4 的字符串数组：如字符串只有一个元素（没有空格），输出数组4个元素都是那个字符串；有两个元素（一个空格），则输出数组则是两个元素的顺序重复；有三个元素（两个空格），则输出数字前三是三个元素，第四则是第二个元素；有四个元素（三个空格），则按顺序平铺。

这通常在 CSS 的 padding、margin 上使用，可以想一下是不是实现相同？

原代码是：

function expandValueToFourValues(value) {    var trimValue = value.replace(/\s+/, " ");    var attribValues = trimValue.split(" ");    var valueExpanded = [];    if(attribValues.length == 4) {        valueExpanded = attribValues;    } else if (attribValues.length == 3) {        valueExpanded[0] = attribValues[0];        valueExpanded[1] = attribValues[1];        valueExpanded[2] = attribValues[2];        valueExpanded[3] = attribValues[1];    } else if (attribValues.length == 2) {        valueExpanded[0] = attribValues[0];        valueExpanded[1] = attribValues[1];        valueExpanded[2] = attribValues[0];        valueExpanded[3] = attribValues[1];    } else if (attribValues.length == 1) {        valueExpanded[0] = attribValues[0];        valueExpanded[1] = attribValues[0];        valueExpanded[2] = attribValues[0];        valueExpanded[3] = attribValues[0];    }    return valueExpanded;}

如果要简化，应该怎么去做？这里直接给出答案，包含函数声明和注释只有 6 行：

function expandValueToFourValues(value) {  // split 方法可以接受一个正则表达式或者函数作为拆分条件，没必要先替换字符串，可以直接切，/\s+/ 表示适配任意白字符  const attribValues = value.split(/\s+/);    // 把输入转换为矩阵，就可以看出单行宽度和索引值是有规律的，直接通过 Array.from() 生成长度为4的数组即  return Array.from({length: 4}, (n, i) => attribValues[i] || attribValues[i-2] || attribValues[0]);}

这是怎么做到的？注释上写着，把字符串拆分后当成一个矩阵来找规律，就是：

这时再来看那个表达式 (n, i) => attribValues[i] || attribValues[i-2] || attribValues[0]，将几个值代入：

当只有一个元素时，假设 i 只有 0 有值：

• [0] attributes[i] 有值，正常加入
• [1..3] attributes[i] 和 attributes[i-2] 都没有值，走到最后 attributes[0]

当有两个元素时，i 只有 0 和 1 有值，按照下面就做到了两个元素重复添加：

• [0,1] attributes[i] 有值，将前两个元素添加进入返回数组
• [2] attributes[i] 没有值，但是 attributes[i-2 = 0] 返回第一个元素
• [3] attributes[i] 没有值，但是 attributes[3-2 = 1] 返回第二个元素

当有三个元素时，i 只有 0、1、2 有值：

• [0,1,2] attributes[i] 有值，将前两个元素添加进入返回数组
• [3] attributes[i] 没有值，则取 attributes[3-2] 刚好取第 index 1 的元素，这就需求惊人的巧合了。

当有四个元素时：

• [0..3] 都有值，依次加入即可

其实这是 CSS 里颜色展开的算法，我怀疑浏览器里可能也是这么简洁实现的，相对原来的代码，这种写法明显简单干净，少了很多判断。

案例二：Canvas 的 textDecoration 实现

Canvas 的 textDecoration 实现并不复杂，只需要处理三条线的起终点即可，但是它有一个问题是它跟 textBaseline 相交，因为 Canvas 的文本画线是从 textBaseline 开始画起的，所以它的装饰线也要考虑到起点：

出于简化说明，这里不考虑 textBaseline 为 alphabetic 的情况，它是从英文的四线格第三线开始画，公式会不太一样。

初看这个图，是不是又要写一堆 if else 构成？不，我们把它展开成一个二维矩阵：

最简单的办法是把 key 合并，成为一维哈希直接取值：

const decorationBaseLineMap = {  'overline top': 0,  'lineThrough top': fontSize / 2,  'underline top': fontSize,  'overline middle': -fontSize / 2,  // ...}// 获取 Y 轴起点const y = decorationBaseLineMap[`${textDecoration} ${textBaseline}`];

但这样还是很啰嗦，而且我从来不觉得拼接字符串是个很快的事情。我们尝试从这个二维数组中发现几何规律，其实它是个很完美的以 middle 和 lineThrough 为中心的镜像：

• fontSize = unerline/top
• fontSize / 2 = lineThrough/top = underline/middle
• 0 = overline/top = lineThrough/middle = underline/bottom
• -fontSIze / 2 = overline/middle = lineThrough/bottom
• -fontSize = overline/bottom =

此时第一反应是给二维数组代数进去，使之前后相等（代什么数字进去，我是凭感觉[狗头]），然后 X 轴和 Y 轴相加结果如下：

此时已经呼之欲出了，有一个隐藏的系数存在于这个公式里，通过它可以做到镜像取反，假设 fontSize = 1，代入到多元一次方程很容易算出来：x = -.5（0.5 去掉整数部分），代入到其它几个公式里，继续验证一下正确性：

• underline/top: x(underline+top)fontSize = -.5*(-1+0)*1 = .5(正数)
• overline/middle: x(overline+middle)fontSize = -.5*(0+1)*1 = -.5(负数).
• lineThrough/middle: x(lineThrough+middle)fontSize = -.5*(-1+1)*1 = 0
• underline/middle: x(underline+middle)fontSize = -.5*(-2+1)*1 = .5(正数)
• overline/bottom: x(overline+bottom)fontSize = -.5*(0+2)*1 = -1(负数)
• lineThrough/bottom: x(lineThrough+bottom)fontSize = 0.5*(-1+2)*1=-.5(负数)
• underline/bottom: x(underline+bottom)fontSize = -.5*(-2+2)*1 = 0

写成实际的代码：

const decorationDim = ({  overline: 0,  lineThrough: -1,  underline: -2,})[textDecoration];const baselineDim = ({  top: 0,  middle: 1,  bottom: 2,})[textBaseline];// 获取 Y 轴值, -.5 是 xAxis 和 yAxis 相加后与字体大小的系数const y = fontSize * (decorationDim + baselineDim) * -.5;

如果写了一堆 if else，会发现这个结果也是相符的，我写了个可公开的范例：Canvas textDecoration (codepen.io)。

总结

希望大家能在开发过程中多进行思考，不要按照需求翻译成代码，而是具备更高的抽象能力，通过一些数学方法，提高代码的执行效率。

本文档介绍了一种结构化的代码管理策略，该策略在各类开源项目中都有实践（例如 Linux、React、Vue)，简而言之的话有以下几个原则：

1. 每个提交（commit）应尽可能小；
2. 每个提交的提交都要是一个内聚的实现；
3. 通过将大问题分解为较小的问题并一次解决一个小问题，最终将大提交变成小提交；
4. 编写清晰的提交消息（commit message）；
5. 代码中在关键位置要保留足够的上下文；
6. 使用无副作用且简洁的实现；
7. 编写足够的测试用例。

提交还是小的好

小型、简单的提交通常比大型、复杂的提交要好。它们更容易理解，更易于测试和更易于查看。理解、测试和审查变更的复杂性通常比变更的大小要快：每次做一件事情的十个200行的变更通常比做十件事的一个2000的行变更更容易理解。

将一个可以做很多事情的更改拆分为每个只能做一个事情的较小更改，可以减少实现同一目标的总复杂度。

而且，即使出现问题，如果只有一个提交，也会很容易进行回滚（Revert）。

每个提交的提交都要是一个内聚的实现

每次提交都应该只实现一个功能或者修复一个问题。通常，这意味着在开发时应将不同的更改分为不同的提交。例如，如果您正在开发功能并遇到先前存在的错误，请清理出干净的 HEAD，修复该问题，然后在此基础上进行新功能开发，这样您就可以进行两项更改，每项更改都有一个单独的提交（修复Y中的错误、添加功能X），而不是一项更改有两个提交（添加功能X并修复Y中的错误）。

将大的问题分解为小的解决方案

同样，将复杂的更改分解为更小、更简单的更改会更好。举个栗子：如果要建设一栋新房子，请不要一次性把整个房子全部完工后直接交付。将其拆分为每个易于理解的较小步骤：从地基开始、然后构建支撑、楼层、外装、室内设计等等，修依次慢慢来，做完一点、检查一点、交付一点。

如果您决定用铲子挖地基或用硬纸板构建框架，则既容易出错，也难以纠正可能埋在地底的误差。每次执行一点，提供足够的上下文，可以让整个架构更加容易理解，每个步骤仅完成所需的步骤即可，并需要使它具备足够的独立性，别的施工跟它无需耦合即可运行。

更改的最小体积应该是最简单的子问题的完整实现，该子问题可以独立工作并表达整个设计，而不仅仅是设计的一部分。您任意将1000行的更改分为十个100行的更改，但是这10个100行的更改可能没有任何意义，并且会增加总体复杂性。真正的目标是使每次更改具有最小的复杂度，行大小通常与问题和设计的复杂度紧密相关。

编写清晰的提交信息（commit message）

最重要的一点是：提交消息应说明您进行更改的原因。

自动化检查能够检查提交消息，但只能强制执行结构，而不能强制执行内容。从结构上讲，提交消息可能应该：

1. 标题，在一行中简要描述更改。
2. 总结，以更详细地描述更改。
3. 也许还有其它信息。

内容远比结构重要。特别是，摘要应说明为什么要进行更改以及为什么要选择要实现的实现。变更本身通常可以很好地解释变更的内容。举个栗子，下面是个完全没有意义的提交消息：

修复了一个 bug

下面这个也好不到哪儿去：

增加了一个正则表达式限制用户名只接受 ASCII 和数字

其实比较好的提交信息是能告诉 Reviewer 这个提交解决了什么样的问题，跟之前代码的区别在哪里，并且提供一下为什么要这么做的上下文，以及这是正确的做法。

限制用户名只接受 ASCII 和数字在之前的实现中并未对用户名加以限制，任意字符都可以通过申请用户，这导致跟其它系统进行交互时发生问题，例如创建用户文件目录时因为受文件系统限制创建失败。这个补丁仅修改了前后端校验逻辑，通过在前端进行输入校验，对输入内容进行限制，避免了此类问题的发生。

具备上下文的注释信息

对于代码评审者而言，其实不怎么关心代码的作用是什么，对于绝大多数代码而言其实是可以读出来的，他们会更关心代码的上下文关系， 这段代码通过什么方式，解决了什么问题：

比如同样一段代码，等待 30 秒：

  // 推送镜像  exec('docker push tag');   // 等待 30 秒  await sleep(3e4);

但是为什么要等待呢，却没有给出原因。但如果按照下面这样写，就很清晰了。

  // 推送代码后，因为仓库存在缓存，直接更新版本会出错，所以等待一下，稳妥起见等待 30 秒确保缓存刷新完成  await sleep(3e4);

确保实现无副作用且简洁

副作用（Side effect）简而言之就是一段代码的实现有两种不同的返回值，阅读体验上会非常糟糕，很难一眼就看出这段代码的作用是什么，为什么不同条件还会有不同的返回值？这些不同的返回值又有何用？

从编译器角度而言，如果不同返回值的类型不同，也会造成优化困难，甚至可能进入 slow path。

比如下面有一段代码，用来找一段数组中，比输入值大的数就返回：

/** * 在数组里面找出第一个比目标数字索引值大的数，如果没有则返回 null */function getLargerNumIndex(arr: number[], target: number): null | number {  let index = 0;  do {    let current = arr[index];    if (current > target) return index;    index += 1  } while (true);  return null;}

这个函数有什么问题？粗看其实没什么问题，但是不同的返回值类型在使用它的函数里，就需要进行额外的判断。而且获取索引值的函数里会拿到 null 本身就是个反直觉的设定，一般都是拿到 -1 才是。

从执行层面来说，现代 JS 引擎会对这种情况进行优化，但是保持相同的返回值类型也能提升 JS 引擎的识别和执行效率，更少的类型判断代码也能提升执行性能。

所以第一步，就是将结尾的 return null 改为 return -1，这样就保持了返回类型的统一。

如果对 JavaScript 很熟悉的人，还有个更简单的办法是直接使用数组的 findIndex() 方法，直接一行就写完了，这就要求开发同学对数据结构的处理有扎实的基础，一行的代码所能表达的内容却比之前的多行内容一样，但是阅读负担就要少很多了。

function getLargerNumIndex(arr: number[], target: number): number {  return arr.findIndex(n => n > target);}

足够的测试代码

测试代码除了可以保证自身质量的保证意外，对于代码评审者而言，还是代码的使用说明书，很多情况下对于代码的审视都是从单元测试开始的，通过在不同场景内观察逻辑的不同行为和返回值就能知道逻辑的具体工作目标，所以测试代码写得好的话对代码评审者是种减负。

而有些问题质量很差，通常提问者和被提问者讨论了半天都不知所云。那么怎么才能提一个好问题呢？怎么才能让自己的问题很快的得到回答？怎么才能让自己的问题对自己和对别人都有用处呢？

提问前

1. 首先应该尝试用在网上问答社区搜索一下，起码在问别人之前应该问一下 Google，至少也应该使用 Bing 的国际版本，如果能够使用英文表达应该能收获更多回答。如果在一个论坛上提问，搜一下这个问题之前有没有人问过，不要让被提问者去做人肉搜索引擎。
2. 阅读一下帮助文档、常见问题FAQ和源代码（如果有的话），别让别人回答你文档地址。
3. 如果可以的话，自己应该试一试。比如*”x和y哪个快？“就是一个烂问题。一个好一点的问题是：“基于zzzz，我认为x应该比y快，但是我在tttt环境下的测试结果是x比y慢，为什么呢？”*。

如何提问

1. 明确描述标题，比如可以使用目标-差异形式的标题。使用准确的分类，标签（tag）等。
2. 把你的问题写下来，站在一个被问者的角度看看自己能不能看懂自己的问题。我经常发现当我花时间组织自己的语言来描述清楚自己问题的时候，我已经知道我的答案是什么了，或者至少对如何找到答案有了新的想法。
3. 如果是书面提问，斟酌一下字句，最好别有错别字、语法错误。更重要的是，如果粘贴代码，确保你的代码能编译通过！！！（除非你标明是伪代码）如果要写输入输出，确保他们是对的！！！
4. 注意格式，特别是代码格式。
5. 明确标明哪些是症状，哪些是你的猜测。
6. 简短，别说废话！！！
7. 除非非常肯定，别动辄就说找到了bug，什么东西设计的很烂等等，更可能的情况是你漏掉了什么东西。
8. 找到合适的人或者论坛发问。项目相关请去 Github 上发起 Issue；常规使用可以去 Stack Overflow 或者国内的 SegmentFault；电脑问题可以去superuser；如果是服务器和网管，可以去serverfault。如果针对这个具体问题有相关的论坛、邮件列表的，也可以去那里。
9. 要有礼貌，没有人有义务回答你的问题。

问题应该包含什么

1. 包含问题的背景知识，帮助别人理解你的真正问题。比如你要解决X问题，发现它的一个子问题Y问题你不知道，那么在问Y问题说一下X问题。比如你要解决X问题，你想到了一个解决方案Y，但是你不知道Y怎么做，那么在问Y时说一下你的X问题。
2. 包含问题发生的环境（机器配置、操作系统（版本）、编程语言（版本）、IDE（版本）、调试器等和问题相关的一切信息）。
3. 包含一个最小的可以重现你的问题的步骤。
4. 包含自己尝试了哪些诊断方法，得到了什么输出。尝试过哪些解决方案，遇到的问题分别是什么。自己学到了哪些东西，有哪些是可供被问者参考的。
5. 如果自己已经排除了一些解决方案，说明这些解决方案为什么会被排除，这会有利于别人更好的理解你的需求。

怎么对待别的人回答

1. 问题解决后，给出一个总结，这样是对所有帮过你的人的表示尊重，同时也会帮到以后遇到同样问题的人。
2. 如果别人的回答你没看懂，在继续追问前先做上面提到的提问前应该做什么。

调试服务

前端调试在官网已经有专门章节进行描述，就不多说，这里具体说一下调试常见问题、案例和一些基本原理。

Hippy 已经在 hippy-debug-server 中集成了一套基于 Chrome DevTools Protocol 的调试服务器，启动后在终端进入本地调试界面，便可以进入远程调试模式。

目前 iOS 和 Android 都已经支持了真机调试，Android 通过 adb reverse 命令直接实现了本地调试端口的转发，就是指在手机上访问 localhost:38989 的调试端口时，访问的实际是开发机上的 38989 端口，但是 iOS 需要终端和前端的双方面配合修改端口才可以做到真机调试，所以建议先通过 iOS 模拟器进行调试工作。

启动调试服务、进入终端的本地调试环境后，JavaScript 代码将会通过调试服务加载到真机中运行，如果代码没问题应该能正常运行，但有时候会碰到启动就 Crash 的情况，可以参考常见案例最后一条“iOS 版本低于 9 时模拟器报告 SyntaxError”。

同样的，iOS 上有的特性有的能用 Polyfill 解决，但有的不行（例如 Proxy、正则表达式的 Sticky Flag 等就需要 iOS 10 以上才可以使用，而且无法 Polyfill），所以如果要兼容低版本 iOS，要注意不能使用到太新的 JS 特性。

秘技：整合到终端内的前端 jsbundle 包调试

该方案暂时只适用于 iOS

有的 App 调试模式下运行很正常，但是打完包集成进去以后就挂了，这时候我们需要用到整合后的 jsbundle 包调试大法了。

其实非常简单，Hippy 在 iOS 中时通过自带的 JavaScriptCore 运行的，所以可以通过自带的 Safar 进行调试，在 Safari 的设置 -> 高级打开开发者菜单后 ，启动 Hippy 就能看到多出了一个模拟器设备。

然后就可以用 Safari 开始调试了，唯一要注意的时，断点需要在启动后才生效，启动时是断不下来的，启动问题可以在关键点加上日志，日志能够正常输出。如果是其它启动后问题，可以直接打断点，跟 Chrome 调试服务的使用方法基本一致。

内存占用情况

前端开发普遍对内存占用缺乏概念，直到终端同学过来说 JS 内存占用太多把 App 搞崩溃了才回过神来。

JavaScript 目前主要以标记清除算法的方案来进行内存回收，它的核心是定期从全局对象中遍历所有对象，并且对不可到达的对象进行标记，并进而清除。

在绝大多数情况下作为前端开发确实不需要关心内存占用，但是 Hippy 中不太一样，Hippy 是前端的开发方式去开发终端 App，有几个类在组件卸载时一定要记得销毁，包含了 React 中负责事件监听的 EventEmitter 实例、Animation/AnimationSet 动画组件，Vue 中的 $app.on() 终端事件监听等等，不释放掉它们，它们就会一直占用着内存，随着界面越来越多，App 最终将会崩溃。

其实调试方法也非常简单，直接在调试器的 Memory 观察内存占用情况，打快照看一下当时各类对象对内存的占用情况，它是 Hippy 在浏览器里运行的容器，可以代表 App 的整体内存占用情况。

这部分内容 Google 官方也有文档。

常见案例

1. 数据已经更新，但是界面内容或者样式不变

这是经常碰到的，最直接的方式是对 React 和 Vue 进行界面绘画的模块 - UIManagerModule 的三个方法 - createNode、updateNode、deleteNode 打断点，其实不管 MVVM 怎么做，最终都会通过这三个方法把界面通知终端画上去，这其实也带来了无限的扩展性，任何框架只要对接了这三个方法就可以进行 Hippy 绘制，如果掌握了 UIManagerModule 的语法，甚至不需要 React 或者 Vue 也可以直接通过它画界面。

但从一定程度上来讲，Hippy 画界面的方式其实跟浏览器是不一样的，它是异步的，MVVM 里组件创建完毕，componentDidMount 或者 mounted 后，其实并不意味着界面真的画上去了（但是这个耗时极少，mounted 后基本可以认为真的画上去了），如果要对界面进行操作，需要确定终端确实画上去了才行，这可以通过 onLayout 事件获得；其次可以看到画界面和普通的 Native Module 调用没有本质区别，最终都要通过 JSBridge 进行通讯。-- 这部分正在通过 C++ 方式重写。

通过观察它，我们可以了解到最终通过 React、Vue 解析后的组件是什么样的，可以观察到为什么界面没有更新，或者样式不如预期。

Hippy 的前端框架在开发初期就考虑到了调试的便利性，调试模式下会将前端框架与终端之间的通讯都打印到 Console 里，当觉得自己的业务 App 或者框架显示存在问题时，直接观察它就能很方便获得所有信息。

以 Hippy-Vue 为例：

Hippy-Vue 要关闭该功能只要将入口文件中的 Vue.config.silent 改为 true 即可；Hippy-React 要关闭该功能需要在启动参数里增加一个 silent: true。不过一般不建议关闭，它在打包后会自动停止输出。

2. ScrollView（Vue 的 div + overflow-x/y: scroll）或者 ListView（Vue 的 ul/li）无法滚动

在 Hippy 中只有这两种 View 是可以滚动的，剩下的都不可以滚动，但是要让它们能滚起来也不是那么简单，需要有样式进行配合，简单说就是：

• ScrollView 以上所有父节点都必须有一个固定的高度，ScrollView 中只能嵌套一个内容子节点，它可以随意变高。
• ListView 以上所有父节点都必须有一个固定的高度，里面所有的 renderRow 出来的 ListItemView（Vue 中的 li）可以随意变高。

这里的固定高度可以是直接指定高度，也可以是通过 flex 进行界面动态分割的高度，但是一定要是固定的，因为滚动实际是终端去实现的，它需要能够区分可以滚动和不可以滚动的区域，如果容器高度和内容高度一样，那就变成不可以滚动了。

另外 Vue 里的 ul 默认已经加上了 flex: 1 样式会把整个 View 撑满屏幕，一般情况下不用做特别处理，但是 div + overflow-x/y: scroll 依然需要手工指定高度。

当滚动出现异常的时候，可以通过 XCode 调试一下终端代码，它有个 Debug View Hierarchy 功能，可以非常直观地看到界面层级和尺寸，对调试样式问题有很大帮助。

3. ListView（Vue 里的 ul/li）性能很差、卡顿、闪烁

这里需要提到前端三点非常需要注意的地方：

1. 如果界面发生异常闪烁，首先需要通过第一个小章节里的 UIManagerModule 观察法，看一下那那三个方法是否有异常的执行，例如 updateNode 执行过于频繁，或者 deleteNode/createNode 异常执行，这通常发生在数据有变化导致界面重绘，可以通过调用栈看一下是哪里的数据更新导致界面重绘，并针对性地进行前端优化。
2. ListView 决定界面是否重绘，有个很关键的参数是 key（React 官文、Vue 官文），Hippy-React 也通过 getRowKey() 的方法实现了 key 在 ListView 中的应用。key 其实是数据的唯一标示符，数据不发生改变，key 就不应该发生改变，而 key 一旦发生改变 ListView 就会重绘。目前很多业务在开发时 key 不指定，或者把 index 作为 key，前者会导致 ListView 每次有数据更新都做一次完整的 Array diff，开销非常大，后者会导致删除中间一个节点时将后面所有的节点全部删除再重新插入一次，开销也非常大。处于性能考虑，key 是必须要加的，一般跟数据的主键保持一致即可。
   **但是：**如果 ListView 中的数据需要进行排序，那就不要指定 key 了，目前 Hippy 的 moveNode 功能，已经计划但仍未完成，指定 key 后在重新排序时会因为对应索引的 key 值不同，先删除全部节点内容，再全部重建，可能会造成轻度闪烁。如果此时不指定 key，就只有一个更新节点的请求，两次请求合并为一次，终端层会对数据进行对比并更新节点内容。
3. 如果到这一步终端渲染依然很慢、帧率低，我们就要提到另外一个参数 type 了，对应到 Hippy-React 里是 getRowType() 方法，它是用来表示组件样式的，样式不变，type 就不变。这里需要先说一下 Hippy ListView 的复用机制，当不指定 type 时，每次有新的 ListItemView 被渲染（HippyReact 里 renderRow() 将返回 ListItemView，Hippy-Vue 里的 li），终端都会重新构建所有终端组件节点，加了 type 之后，会将将之前渲染过的终端组件节点放到缓存池中，下次碰到相同 type 类型的 ListItemView，就不会重新渲染，而是从缓存池中把缓存的节点拿出来做次拷贝并更新数据，再上屏，即使只有一个样式的 ListItemView，通过 type 也能做到性能优化。

经过上面三步，能解决 90% 的 ListView 性能问题。

Hippy-Vue 官方范例中也对这三个参数加了注释。

4. iOS 上 ListView 不渲染，但 Android 没问题

首先需要检查 numberOfRows 参数是否真的是 ListView 中 ListItemView 的数量，这个除了在业务代码中打断点查看数据数量是否和 numberOfRows 一致以外，也可以通过第一个 UIManagerModule 的调试方法查出来。

这个问题牵扯到 iOS 上一个 ListView 的上屏性能优化，iOS 上并不是发一个 ListItemView 就上屏一个的，而是需要先改变 ListView 的 numberOfRows 再去创建节点，当节点数量与 numberOfRows 一致时再上屏。

目前碰到的所有不渲染的问题都是因为这个原因造成的。

另外在 Hippy-Vue 中，对于静态的 li（就是终端的 ListItemView），可以不需要手工指定 numberOfRows，Hippy-Vue 会在 DOM 层计算子节点数量。但是对于动态获取的数据，也必须要加上该参数，因为 Hippy-Vue 位于 Vue 的渲染层，跟业务还隔了一个 Vue，无法知道业务到底有多少数据准备要渲染。

5. iPhone 中红屏报告 ModuleNotRegist

这里需要提到 Hippy App 的启动方式：当终端 JS 引擎加载完 JavaScript 后，会从 GLOBAL.appRegister 对象里去寻找终端指定的 moduleName，而 __GLOBAL__.appRegister 是在 Hippy 启动时通过 HippyRegister.regist() 方法注册上的，在 Hippy-React 入口文件 或者 Hippy-Vue 入口文件 定义的 appName 最终都会执行到 regist() 方法上进行 __GLOBAL__.appRegister 的注册，首先，我们要检查终端的 moduleName 是否和 appName 一致。

如果一致依然出错的话，很大几率是之前 JS 执行失败，也不排除 SDK 更新后存在 bug，也有可能其它问题，导致 __GLOBAL__.appRegister 未注册成功，但我们有个办法可以在该错误抛出时二次确认一下终端所寻找到 moduleName 是否和前端定义的 appName 一致，可以在那一行打上日志，然后使用上文的 Release 包调试方案检查终端过来查的到底是什么 appName。

6. iOS 版本低于 9 时模拟器报告 SyntaxError

这是因为 Hippy 自带的 Webpack 默认调试模式配置文件，最低仅开启了 iOS 9 的输出，因为输出到 iOS 8 会多出很多 polyfill，语法上也会转换，导致体积大很多。

Hippy 本身最低支持的 iOS 8，我们建议在高版本的 iOS 上进行调试，然后打包后在低版本 iOS 走一遍测试流程，没什么问题即可。

如果非要在低版本的 iOS 上进行调试，修改一下 webpack 配置文件 iOS 将 preset-env 中的 ios 版本改成更低即可，但目前经过测试 core-js 对 iOS 8 那样对低版本可能存在问题，这就需要你自己手工调整了。

Error 对象在 JS 中貌似是一个长期被忽略的对象，很多人宁愿用别的方法来描述错误，例如一个特别类型的返回值，或者通过返回码，但其实这个对象从 ES1 里引入开始就带来了无限的可能性。

笔者开发代码的时候，一直偏好将函数的正常输出和异常分开，类似这样：

function mustBeEqual(a, b) {  if (a !== b) {throw new Error(`${a} is not equal with ${b}`);  }  return true;}try {  const equal = mustBeEqual(1, 1);  console.log('1 is equal with 1');  const equal2 = mustBeEqual(1, 2);  console.log('1 is equal with 2');} catch (err) {  console.error(err.message);  console.error(err.stack);}

可以看到正确的输出和错误的输出泾渭分明：

我一直觉得这样的写法有几个好处：

1. 可以将异常逻辑和主流程逻辑分开，从而使可读性更加清晰。
2. Erlang 中有一句话叫做：“Let it crash”。 - 这不是说让程序真的崩溃了，而是提醒开发者小心处理每一个错误，有的时候崩溃了会更加容易发现问题所在。
3. Error 对象的一些属性，例如 stack 对于发现问题所在位置其实非常有帮助，它对于还原问题帮助非常大。

Error 对象的具体参数请参考一下 MDN，就此不再多述: https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Error

我只想说 Error 的主要用法。

继承出业务错误类型。

在项目开发中，会碰到各种各样的网络、数据库、外部 RPC 调用，各种问题出现之后难以以一种统一的方案去解决。

此时其实可以通过继承几个业务错误，把底层错误转换为自己项目中所使用的，二次抛出后进行处理。

例如下面代码，摘取自 http://git.code.oa.com/weplus/serverplus/blob/master/src/errors.ts 这里是 Typescript 的语法。

/** * Base Error */class BaseError extends Error {  public status: number;  public code?: number;}/** * Request not passed validation will trigger */class BadRequestError extends BaseError {  public status = 400;}/** * The user was not login */class UnauthorizedError extends BaseError {  public status = 401;}export {  BadRequestError,  UnauthorizedError,}

这样做有几个好处：

上层可以对输出进行统一处理

底层输出只有两种：正常返回和异常，所有的异常都是一个错误的对象，这样就可以简化处理逻辑，对正常输出走业务逻辑，而错误会全部进入 catch 段进行异常处理。

在上面的例子中，HTTP 的状态码就是依靠错误的 status 属性进行确定，当某个业务流程需要返回一个错误时，直接 throw 即可。

摘自 http://git.code.oa.com/weplus/serverplus/blob/master/src/base-model-controller.ts

/**  * Get single record method  */public async get(req, res) {  let authenticated;  try {authenticated = await this.apiAuthenticate(req);  } catch (err) {throw err;  }  if (typeof authenticated === 'boolean' && !authenticated) {throw new this.errors.ForbiddenError('Permission denied', {  requestId: req.headers['X-Request-Id'],});  }  const id = req.params.id;  const result = await this.__get(req, id, req.query, req.params);  return result;}

上面的路由层接收到一个错误，而不是一个正常的返回值时，就会将它作为错误进行输出。

上层也可以通过继承链，找到具体错误的具体类型和原因。

通过 instanceof 去找错误，效率比通过字符串高出数倍不止，可以将程序内的错误，和给用户的提示分开，可以根据不同的错误类型，进行不同的处理。

const err = new TypeError('Something went wrong');err instanceof TypeError// trueerr instanceof Error// trueerr instanceof RangeError// falseerr.message// "Something went wrong"

因为异常本身是可被触发的，它可以干更多事情，例如将错误自己上报给错误监测系统。

在 http://git.code.oa.com/weplus/serverplus/blob/master/src/errors.ts 还可以看到，在基类错误的构建函数中，还有一段 Raven.captureException() 的上报方法，这样我们在这里利用了错误的构建时，将自身连带附加信息一起上报给了 Sentry（Sentry 是什么情参考《Web 前后端错误上报及问题跟踪》）。

/** * Base Error */class BaseError extends Error {  public status: number;  public code?: number;  constructor (message, context: any = {}) {super(message);Object.setPrototypeOf(this, BaseError.prototype);if (!config.sentry) {  return this;}const extra = {  status: this.status,  code: this.code,  ...context,};Raven.captureException(this, {  extra,});  }}

这样一来，当服务器发生异常时候，不用改动主逻辑代码，自动实现了错误上报，这样可以作为一个单独的错误上报层在项目中使用，而且它在上报的时候，还能带上上下文，这样对于错误还原帮助巨大。

还是上面那个例子，这里在非法请求时在返回 Permission Denied 的同时，把前端请求过来的 requestId 一起附带上报，前端整合 Sentry 后可以做全链路的错误还原。

  if (typeof authenticated === 'boolean' && !authenticated) {throw new this.errors.ForbiddenError('Permission denied', {  requestId: req.headers['X-Request-Id'],});  }

面向错误进行应用开发

这种开发模式可以根据场景使用，需要将之前的思维进行小幅度调整，之前 res.code === 0 && doSomethingRight() || doSomethingWrong() 的方式得用 try catch 重新进行梳理，但这样做可以让主线流程代码变得很干净，减少大量的 if else。

面向错误进行开发，需要控制好 try catch 的颗粒度，理论上都是越细越好的，如果一个大的 try 都裹在一起，任何一处发生问题后都会走入 catch 环节这会加大判断错误问题发生位置的难度，尤其是在某些未对底层错误进行二次捕获抛出的架构中会更加严重。

过去和未来

在早期的浏览器引擎中， try catch 方式是比较低效无法被优化的，不过现在新版的 V8 引擎 TurboFan 已经对 try catch 进行了大幅度调整，之前无法被优化的代码也可以以最优方式运行，而服务器端截止本文完稿，搭载 TurboFan 的 Node 8 已经进入 Stable，预期 10 月份进入 LTS，这会让 try catch 的使用更加放心。

面向错误进行开发这种开发模式其实在 Java、Python 或其它语言中已经非常普遍，但在 Javascript 领域目前感觉比较好的是 NodeJS 上的 ORM 库 Sequelize，它里面对错误都进行了良好封装。

我希望未来这样比较小，但是有用的开发模式能更加普及。

Git 历史和现状

Linux 的作者的另一个作品，2002年时他还在使用 Bitkeeper 作为 Linux 内核的版本管理，但因为它是 Copyright 有版权的软件备受质疑，然后 Andrew Tridgell 对 Bitkeeper 进行逆向工程，导致 BitMover 要回收 Linux 开发者的 Bitkeeper 的免费使用权，Linus 一怒之下花了10天写出了 Git。

名字的意思是：混蛋 - egotistical bastard

如今 Git 已经成为绝大多数开发者的选择， Tom Preston-Werner、Chris Wanstrath 和 PJ Hyett 在 2007 年 10 月推出的 Github 已经成为了全球最大的开发者网站，我们厂在上面也是贡献颇多。

更有甚者，一向自己造轮子的的微软，也打算把巨达 300G 的 Windows 源代码迁移到 Git 上进行管理，他们为 Git 提供了新的 GVFS 实现，有效地改善了 Git 对巨大代码仓库的性能。

另外说一句：Docker 的二进制 image 管理，也是基于 git 实现的。

集中式版本管理和分布式版本管理

Git 和 SVN 是从设计理念上就不一样的版本工具，SVN 将代码进行中心化管理，拥有更好的稳定性和安全性，但是去中心化的 Git 却是从 Linux 操作系统的开发需求而来，更加适合多人协作的开源项目，可以以任何一个点为 remote 将他的代码与本地代码合并，随着时间发展，还衍生出了更多强大功能和一整套操纵流程，让它也可以适应了商业软件的开发。

Git 和 SVN 代码历史的不同

SVN 的代码历史相对比较简单，因为它是中心化的，所有人的代码都直接提交到某个 repository 上，所以它的 Reversion ID 号是一个按顺序增加的数字类型，一般情况下不能在两个数字之间插入别的 reversion。

Git 的看起来就是杂乱多了，它的 Reversion ID 号是一个 40 位长度的 hash 值，通常也可以缩写为 7 位，这样做的原因是因为 Git 的最小单位是代码修改的历史，即为补丁 Patch，而分支、 Tag、Remote（一会儿会说到这些概念）等都只是分支的集合，互相之间可以随意拆分、合并。

我更愿意把分支、Tag、Remote 想象成不同的平行宇宙，因为某些机缘导致产生了分裂，走向了不同的历史，也可能因为某些机缘又合并到了一起，变得更加强大。

Git 基础命令

Git 按照场景可以分为以下场景（Scence）：

1. Workspace：当前工作区，修改的的最初状态。
2. Staging：修改后，添加到准备提交的缓存状态。
3. Local repository：本地的代码仓库，只对自己的代码生效。这也是和 svn 区别之一，svn commit 之后就直接提交到远程服务器了，git commit 之后只是到本地代码库。
4. Remote repository：远程代码库，将自己的本地代码库同步到远程代码库上，这样可以供别的开发者分享自己的成果。

具体流程看图即可，下面对几个常用命令进行简单介绍

*PS: 图中没有提到 rebase 和 cherry-pick 命令，这两个命令也非常强大，后面有提到，有时间可以关注一下 *

补丁 diff

之前有提到过，补丁是 Git/SVN 代码版本管理的基础概念，它其实是以行为单位的文件修改历史，增加行以 + 号开头 ，删除行以 - 号开头，而修改一行，就是先 - 后 +。

在 Git 里可以通过 git diff 或者 Linux/Mac/Conemu 中，也可以通过 diff -Naur 来生成文件对比结果，有点类似下图。

这是整个代码管理的基础概念，所有的分支、Tag、Remote 都是在此基础上衍生的。

基本流程

1. 克隆代码到本地开发环境 - Clone

$ git clone [REPOSITORY_URL]

对应到了 svn checkout 命令，用于把远程代码克隆到本地，跟 svn 一样，REPOSITORY_URL 的协议非常灵活，之前流行用 ssh/scp 协议，但现在 https/http 协议渐渐流行起来了。

2. 更新代码 - Status/Commit/Log

刚有提到过 Git 的四种场景，其中前两种场景需要通过

$ git status

命令查看，代码刚刚新建可以看到是 Untracked files（Workspace） 状态，执行 add 之后变成 Changes to be commited（Stage） 状态，修改了 Stage 中的文件，又会变成 Changes not staged for commit 状态。
执行 commit 之后就从 Stage 中转移到了 Local repository 中，可以通过

$ git log

查看到代码提交。

3. Branch 和 Tag

如刚从所说，Branch 和 Tag 都可以看成是补丁的时序化集合，branch 可以互相合并，在 clone 完 repository 后有一个主线分支叫做 master。而 Tag 用于发布后标记版本，这两个只是从名字上不一样，功能（我感觉实现上）并没有太大区别。

和 SVN 不同， SVN 的 Branch 和 Tag 都是把 Trunk 整个代码库拷贝出来，Git 只是将补丁引用重新对当前代码应用一下，所以 Git 的 Branch/Tag 都非常轻量，切换起来非常轻松，使用 Git 要尽量多使用它的分支来提高开发效率，一会儿提到 Git flow 时会描述一下如果用分支进行代码功能开发管理。

3.1 新建分支的两种办法

$ git checkout -b [BRANCH_NAME] # 在当前版本切换并新建分支$ git branch [BRANCH_NAME] # 直接新建分支

3.2 切换分支

$ git checkout [BRANCH_NAME] 

3.3 合并分支的两种办法

$ git merge [BRANCH_NAME] # 将另外一个分支的代码，打到当前分支之后。$ git rebase [BRANCH_NAME] # 不推荐，对代码进行比较，将本分支修改后的代码打到另外一个分支之后

rebase 通常情况下不推荐使用，因为 rebase 完下游分支，再从上游分支 merge 的时候会丢失分支合并的 commit，但是对于部分有 history mysophobia 的人来说，它是保持代码提交历史记录干净的神器，那个 Merge branch 'xxx' of http://github.com/xxx into yyy 的 commit 看起来也挺讨厌的。

对于已经推到 remote repository 的 commit，是不建议 rebase 的，因为一旦 rebase 了，别人再 pull 就会出一大堆的冲突 conflict，而且基本没法修，通常情况下还是建议用 merge 稳妥一些。

PS: rebase 还有一个强大的功能是配合 --interactive 参数修改之前的补丁，具体自己查一下，但是改完了 push --force 上去，别人再 pull 回来出 conflict 是必然的，但是这招是修改 Github 上的 Pull request（后面有提到）必备技能。

3.4 删除分支

$ git branch -d [BRANCH_NAME] # 已经合并到 master$ git branch -D [BRANCH_NAME] # 该分支未合并到 master，强制删除

PS: 即使删除了分支等，也可以用 git reflogs 找回来喔

3.5 取消修改

git stash # 取消全部修改，很强大的是它可以恢复过来，具体自己查一下git reset —soft [REV] # 保留修改内容，从 Local repository 中撤销，也可以用于回退历史记录git reset —hard [REV] # 丢掉修改内容，从 Local repository 中撤销，也可以用于回退历史记录

推送本地代码到远程仓库

推送代码是为了跟别人一起合作，命令行非常简单

$ git push [REMOTE] [BRANCH]

remote 默认为 origin，如果不填的话就推送到它上面，branch 默认为当前分支，其实可以不加，加了就把指定的分支推送到远程了。
如果要将推送本地功能分支，建议 push 后面加上 —set-upstream 参数。

郑重警告：**永远不要对主线 master 分支执行 —force **

获取远程分支更新

$ git pull # 把代码更新到  workspace$ git fetch # 把代码更新到 Local repository，可能需要通过 merge 再合并到 worksapce 一次。

远程仓库

Clone 之后会有一个默认的远程仓库为 origin，但如果还要增加别的远程仓库，就需要用到下面命令了：

$ git remote add [REMOTE_NAME] [URL] # 添加原创仓库$ git fetch [REMOTE_NAME] # 获取远程仓库更新$ git branch -a # 查看包括远程仓库以内的所有分支$ git push [REMOTE_NAME] [BRANCH_NAME] # 推送到远程仓库

Github Pull Request & Gitlab Merge Request

Github 在 Git Remote 的基础上为了方便大家参与开源项目，衍生出的一套机制，目前常规开源项目的参与流程是，先注册一个 Github 账号，然后将感兴趣的开源项目 Fork 一份到自己的 namespace 下，然后拆分分支进行修改，然后提交到自己的 Github repository 下，再发起一个 Pull Request，让项目维护者来合并你的代码（Pull request 名副其实），在这个过程中，项目维护者会对你的代码进行 Review 和点评，你得按照维护者要求进行修改（这里 rebase 会用得很勤），修改通过，维护者同意后，就有他将代码合并进项目中。

具体流程自己走一圈就明白了，Gitlab 的 Merge Request 原理是一模一样的。

PS: 范例图片在 PPT 的第 22 页起

Git flow

Git flow 本来应该是本文的重点内容的，它是在 Git branch 的基础上实现了一套简单的功能模块化开发流程，主要思想是把分支分成了上下游几个层级，然后通过一套命令行工具进行维护。

1. master 分支 - 与线上版本保持一致，当发生线上问题后可以很轻松地修复。
2. develop 分支 - 功能开发基线分支，功能开发完之后合并到上面，所有功能开发完毕后经过测试上线，然后合并回 master。
3. feature/* 功能开发分支 - 从 develop 上拆分，也需要随时把 develop 的更新 merge 回来，跟上游的分支保持一致，等功能开发完毕之后，即可合并到 develop。通过和上游分支保持一致，这样可以避免对误删别人的代码，所有代码冲突必须在下游分支修好，测试完毕后才可合并到上游分支。
4. hotfix/* 热修复分支 - 主要用于线上 bug 修复，但是修复后应该同时合并到 master 和 develop 两个分支上。

然后 git flow 提供了套命令行工具来更加轻松地去做这些代码合并的事情。

$ git flow init # 初始化 git flow 分支模型$ git flow feature start [NAME] # 开始一个功能分支$ git flow feature finish [NAME] # 将功能分支合并进 develop$ git flow hotfix start [NAME] # 开始一个热修复分支$ git flow hotfix finish [NAME] # 将补丁合并进 develop 和 master$ git flow release [NAME] # 发布一个新版本，打 tag 

感觉 Git flow 得有个篇幅，下次有机会再来详述。

其它内容

有兴趣可以继续看一下别的相关内容，非常有意思：

1. git svn - Git 可以以 svn 为代码后端，通过 Giit 来对 SVN 里的代码进行版本管理。
2. git reflogs - 引用记录，在 git 中误删除某提交是不用害怕的，只要 commit 了，就可以通过 reflogs 找到，用 reset 或者 cherry pick 恢复。
3. git cherry pick - 摘樱桃（commit），从另一个分支中单独将某个 patch 摘回来。
4. git bare repository - 建立 Git 服务器
5. git submodule - 子模块，一个大项目可以通过 submodule 进行拆分，可以随时进行子模块的版本更新和回溯。
6. git hooks - 钩子，当 git 在 repository 上发生某种行为的时候，可以通过钩子触发一些行为，像目前 Github 上的一些第三方持续集成服务，就是在此基础上实现的。
7. git signature - 签名，通过 gpg 在 commit 时对 patch 进行签名，证明那个补丁确实是自己提交的，可以参考一下 Github 的文档。
8. Source Tree - Source Tree 是一套跨平台的 Git 图形界面，简单方便，我目前主要用它进行基本的 Patch 阅读，比命令行更加舒服。

多谢阅读，下次有机会再写。

在做国际化项目中，服务器端时间转换为用户本地时间一直是个问题，其实浏览器本身已经提供了这样的能力，而且它可能比想象中更加容易。

时区（Time Zone)是地球上的区域使用同一个时间定义。1884年在华盛顿召开国际经度会议时，为了克服时间上的混乱，规定将全球划分为24个时区。
在中国采用首都北京所在地东八区的时间为全国统一使用时间。 - 百度百科

时区，做国际化项目中肯定会遇到，因为不同人所在地区不同，时间也是不同的，从这点来说，时间和地区也是相对的。传统处理时间的方式是将本地时间序列化成类似“2014-04-14 13:10:28”这样的字符串，这样的缺点显而易见，一是将时间转换为这样的字符串，需要额外的代码，因为日期格式不一定，这样的需求作为 Javascript 的语言根本不会去处理，换而言之，这样的字符串虽然方便人类阅读，但是却不利于计算机处理；二是这样只记录了本地时间，当一个项目走向国际化就需要一个单独的时区字段来进行转换，同样的另外一个时区的人提交数据的时间也需要额外的转换工作，这样既增加了冗余，同时增加了整体系统复杂度。

操作系统的解决方案

无论是 Windows、Linux 还是 macOS，他们也面临着相同的问题，所以操作系统的设置中都会有一项“日期和时区”配置，这样的配置也为所有应用程序所共用，包含浏览器，所以浏览器是自带时区支持的。

以 macOS 为例：

sudo systemsetup -gettimezone> Password:> Time Zone: Asia/Shanghai

浏览器中的时区

浏览器通过 Date instance 的 getTimezoneOffset() 方法提供了获取当前环境中时区的能力，它返回了当前时区和 UTC 时区按分钟的偏移量，即当前时间加上偏移量，就是 0 时区的格林尼治时间，如果返回的偏移量是负数，则是东区时间，正数则是西区时间。

const now = new Date();                // 获取当前时间now.getTimezoneOffset() / 60;          // 获取时区偏移量> -8                                   // -8 即为东8区

时间序列化 - Date serialization

序列化也叫对象字符串化，其实浏览器已经提供了一个简单方便的方法进行时间序列化，无需拼凑字符串，序列化后的数据可以除了在浏览器环境中，还可以在各类数据库中直接使用，它的名字叫做 JSON.stringify()。 ;-)

JSON.stringify(now)> ""2017-04-14T05:11:42.247Z""

其实序列化后的时间，会被转换成格林尼治时间。

这样的字符串可以直接以 Date 类型保存到数据库中，取出来的时候，使用 JSON.stringify() 进行序列化，自动就会转换成这样的日期格式，而不用再手工处理。

以 Sequelize 为例：

const aModel = require('./models/im-a-model');aModel.default.findOne().then(model => console.log(JSON.stringify(model.dataValues, null, 2)));> {>   "id": 1,>   "name": "某某某",>   "createdAt": "2017-02-14T19:32:15.000Z",>   "updatedAt": "2017-04-06T18:08:53.000Z"> }

时间反序列化 - Date deserialization

将字符串恢复为对象，即为反序列化，常规我们在将 JSON 对象反序列化时，最常用的还是 JSON.parse() 方法，同样的 Date 也可以这么做。

var dateStr = JSON.stringify(now);JSON.parse(dateStr);> "2017-04-14T05:11:42.247Z"

不过此时它还是个字符串，因为 JSON 序列化成字符串后已经丢失了对象的原始信息，要将该日期重新赋值到 Date 对象中才可以更加方便地使用。

new Date(JSON.parse(dateStr))> Fri Apr 14 2017 13:11:42 GMT+0800 (CST)

我们可以看到时间已经从格林尼治时间恢复为东8区的北京时间了。

结论

以上代码已经简单地说明了时间对象的序列化、保存、反序列化的步骤，希望能对应用开发带来一些帮助。

在做开发过程中，通过原始的对象进行操作带来的便利性比拼凑字符串要强很多，原始的数据或者对象也很方便进行二次加工，这是浏览器自身就具备的能力。

题外话 - 时间对象的操作

说到时间对象，其实 Javascript 本身的能力是很弱的，即使是将日期对象转换为一个人类可阅读的、指定格式的字符串都很不容易，遇到这样问题的开发者并不只有我们，所以有人开发了一个很强大的时间日期处理库 - moment.js，同样是将日期对象转换为字符串，它的 format() 方法异常强大，例如：

moment(now).format('YYYY-MM-DD HH:mm:ss');> "2017-04-14 13:11:42"

它同样提供了增减时间、两个时间判断大小等等一系列功能，moment 对象在使用时比 Date 更加方便。

目前它已经和 lodash 一起成为了前端项目开发的基础库之一了，更多功能等待你的发掘。

前端在上传文件时，往往会要求指定上传的文件类型，可能是图片、可能是视频、可能是一个 Word 文件，依靠文件扩展名只能进行简单校验，但是如果碰上文件没有扩展名，或者扩展名与文件的实际类型不一致的情况，后果可能是后期服务器端处理时发生问题。

所以需要一个更加靠谱的方案，不是依靠文件扩展名，而是实际的文件内容进行类型判断。

Linux/Mac/Unix 中检查文件类型的方法 - 没兴趣的同学可以略过此章节。

通过扩展名进行类型判断准确而言应该是从 Windows 操作系统的传统，但类 Unix 操作系统不依赖文件扩展名的特性（很多文件根本没有扩展名，最典型的就是 /bin 下面的可执行程序），所以它们最需要文件类型推断功能。

提供此功能的命令叫做 file，它已经被包含在大多数 Unix 系统中，基本的使用方法是直接使用 file [文件名] 即可显示出它的文件类型，例如：

$ file logo.pnglogo.png: PNG image data, 556 x 36, 8-bit/color RGBA, non-interlaced$ cp logo.png logo-real-png.gif # 复制一下改一下扩展名$ file logo-real-png.gif # 继续探测，可以发现检测出的文件类型不变，logo-2.png: PNG image data, 556 x 36, 8-bit/color RGBA, non-interlaced$ file test.txttest.txt: UTF-8 Unicode (with BOM) text

file 就是传说中不依靠扩展名直接对文件内容进行推断的命令，基本原理是文件内容中的特征码进行检测，具体方法后面再说。

文件类型的标准 - Mime Types

在前端开发中应该能接触到 Mime Types 这个概念，它是文件类型的一个标准，通过将文件进行分组归类的方式，可以很轻松地识别该文件属于什么类型、具体是什么格式，很常见的有 text/html - HTML 文本、text/plain - 纯文本、image/jpeg - JPEG 图片、image/png - PNG 图片等等，text 就是文本类型分类，而 image 是图片类型分类，后面的就是具体格式。

具体的请参考 mime.types - Wikipedia 在此对它的概念不多说。

同样的，file 命令也能够输出 Mime Type，参数是 --mime，依然不依靠扩展名，而直接检查文件内容，在输出 Mime Type 时还会把字符集显示出来。

$ file --mime logo.png logo.png: image/png; charset=binary$ file --mime logo-real-png.giflogo.gif: image/png; charset=binary$ file test.txttest.txt: text/plain; charset=utf-8

完整的 Mime Types 类型如果是 Linux 系统可以去 /etc/mime.types 下找到。

通过 Javascript 简单地获取 Mime Type

做前端开发时，很有可能会通过限制扩展名来进行可上传文件约束，这可以通过 input tag 的 accept attribute 进行限制，但在某些情况下可能无需限制，但需要知道上传文件类型，常规做法是做一个扩展名的类型分类，根据扩展名进行分组，但其实绕了弯路。

Web 引擎早已经提供了基于 Mime Types 的类型了，范例代码非常简单。

var input = document.createElement('input');input.type = 'file';input.multiple = true;input.addEventListener('change', evt => [...evt.currentTarget.files].forEach(f => console.log(`${f.name} type is ${f.type}`)));

关键就在于 input.files 这个 FileList 对象中的每个 file，它是一个 File 对象，会有一个 type property，记录了该文件的 Mime Type，这个范例代码可以一次选中多个文件，多个文件的 Mime Type 都能直接输出，这是几个测试文件后的输出结果，依然有刚才被重命名的 gif 实际为 png 的图片：

> input.click()logo.gif type is image/giflogo-real-png.gif type is image/giflogo.png type is image/png

** 但是，这里有个问题 - 浏览器的文件类型推断依然是基于扩展名的，并不能做到重命名扩展名后，对文件内容的推断，logo-real-png.gif 本来应该是 png 但是却识别成了 gif。**

我查了一下，未来浏览器会实现这个功能的，但是这个标准名为 《MIME Sniffing》，今年3月才刚刚更新，各大浏览器还不能支持。

所以需要手工来进行检测了。

文件特征码

以前了解过杀毒软件的，可能会知道计算机病毒都有特征编码，这些编码标志着该段代码可能会干点奇奇怪怪的事情，让你的电脑不正常。

同样的，每一种文件类型也都有自己的编码，比较好识别的是文本类型的文件，只要所有字符集都在 Unicode/Ascii 编码范围之内，肯定就是文本类型了，如果有兴趣打开一个 zip 包，或者 Java 编译后的 jar 文件，可以看到开头一定是一个 PK，PK 是 Phil Katz 的名字缩写，那是另一个有趣的故事了。

但是，并不是每个 PK 开头的都是 zip 包，后面还会有一些其它二进制编码来告诉计算机，它是某种类型的文件。

只需要知道，每种文件类型，都会有不同的特征编码，那就够了。

通过 Javascript 来实现基于文件内容的类型检测

这里需要用到 FileReader 方法，它可以直接通过浏览器中将文件以 ArrayBuffer 形式读入内存，通过 Javascript 进行处理。

先贴完整代码：

var input = document.createElement('input');input.type = 'file';input.multiple = true;function detectFileType(file) {  // Fallback when browser was not supported FileReader.  if (window.FileReader === void 0) {    return console.log(`${file.name} type is: ${type}`);  }  // Start detecting  var fileReader = new FileReader();  fileReader.onload = function(e) {    var arr = (new Uint8Array(e.target.result)).subarray(0, 4);    var header = "";    for(var i = 0; i < arr.length; i++) {      header += arr[i].toString(16);    }    // Check the file signature against known types    switch (header) {      case "89504e47": {        type = "image/png";        break;      }      case "47494638": {        type = "image/gif";        break;      }      case "ffd8ffe0":      case "ffd8ffe1":      case "ffd8ffe2": {        type = "image/jpeg";        break;      }      default: {        type = "unknown"; // Or you can use the blob.type as fallback        return console.error(`Unkonwn ${file.name} type header: ${header}`);      }    }    console.log(`${file.name} type is: ${type}`);  };  fileReader.readAsArrayBuffer(file);}input.addEventListener('change', evt => [...evt.currentTarget.files].forEach(detectFileType));

执行结果如下，这一下文件类型都被正确检测出来了：

> input.click()logo.gif type is: image/giflogo-real-png.gif type is: image/pnglogo.png type is: image/png

解释一下：

FileReader 的 onload 方法可以在文件加载完成之后进行一些处理，同样的它是异步的，可能随着文件大小不一致执行顺序有所差异。

文件加载，首先将文件通过 Uint8Array 转换一些数组类型，然后通过 subarray 截取前 4 个 item，即为文件头，然后通过 toString(16) 转换为 16 进制的字符串。

这段代码只能检测 jpeg、gif 和 png 三种图片类型，除此以外的都进入 unkown 类型分支，因为图片类型的特征码都在文件头部前几个字节就能获取具体文件类型，相对比较好打比方，对于更加复杂的情况或者实现 file 的能力，这是远远不够的。

万能的 npm

npm 上有一个比较复杂的文件类型检测实现 file-type 可以参考一下，它通过文件的前 4100 个字节来进行类型判断，可以判断出的文件类型种类也更加丰富。

1. 数据本身不要求特别的加密措施，只是必须确认提交数据的真实性。
2. 数据来往的双方服务器身份必须能够得到有效识别（https 依然有中间人攻击风险）。
3. 单个请求的数据在特定时间（目前暂定10秒）之后，就必须失效。

背景知识

• 非对称加密

对称加密指的是双方知道密码就能够解开密文，得到真实信息。而与之对应的非对称加密，即使知道密码也未必能解开密文，它由两部分组成，一部分是用于加密数据的公钥，另外一部分是用于解密数据的私钥，加密数据的公钥可以随意传播给任何一个人，但是解密数据的私钥只能由所有者持有，别人使用公钥加密的数据，只能由所有者通过私钥解密。

• 数据散列（hash）

将一段任意长度的内容，经过某种算法，转换成一个固定长度的字符串，但是这种转换是有损的，转换后的字符串没有办法再转回原始内容，这种算法有一个特征是内容中发生任意的细微改变，都将导致结果的巨大不同，通常用于验证数据的真实性。

实现方案

现有业务可以完全不动，最终决定在数据上增加一个签名字段，该签名整合了对方的名称、当前时间戳、和使用 SHA1 256 算法生成的消息内容散列数据，还有一个增加破译复杂度的盐，然后用 RSA 非对称算法进行签名。

具体代码如下，只使用了 openssl 生成公私钥，以及 node 的 crypto 模块：

#!/bin/env nodeconst crypto = require('crypto');// 私钥内容，用于解密签名// 使用 openssl genrsa -out rsa.private 1024 生成const PRIVATE_KEY = `-----BEGIN RSA PRIVATE KEY-----MIICXAIBAAKBgQDdAwx2Srt4i9363PL+RK6o/LF58cbAwX9+IVoQGmBvf8jDJZqACkOBwdRo0LSeTQRBhe5HuuFS3VpatFIoghq069RfeQfOCxH+qzNqYQ+nI5Er3+FK9rZFqfbWjZt7GxSfCjZkcikC1z2mgetleUMow0Pi7SuV0PadbqYt4cC16QIDAQABAoGBAKWGEgBKKiu3PRIUBp0uXU1Mq7Lzw/I7OTwCyIwE5TK8lmSpNhQtG7ADtgymOo/QiJ52KyZnrTe9dl02bc3O2yY+lG1gFeP52zYq0dcAucJqHwyIMPhPsxANgZHXw+8Y3F5L124MWnZ1YOL9ckNDa7sni8OqZNKgQtu8fAmdTPQBAkEA8xtK571bZ5XO3HTqOcbGFy3xe+MHndG24QgNdTeedX1zNOnfVtSOEQa53AK9ImKjMZBd3VlXq+2oGMNa2gWYaQJBAOi7xZg560iDPk/qPscJRgDTyfibAFaV5YNXnPgV4iPWlmn8/KvrvLmd79fyTYaps8SZ65Rz7DjQwSQBMyXSgYECQDDB0IwZ1jM4QHzGlhNwYlpTxJLsPaLRZLRNQSW5Ofamamy6Wyi3CKcxiiUuB3DWB5TxN2IlgQfiakxNIfOIG8ECQHVTzD583Hd26qABGFrg+vCJ1KVHBvmfodAACDstVQ76LGQMTRkiw8bTr0kvdxPvU5hGfHQfqLPP0b6j+DQWFoECQCKLSQIGoJIJ+BQPcWpsO7T4zJxSd2gbvMIsKydtn52qc44/dX59oXkDt2gvDSrGY4Lj/RswNK652ymBIfgKfkI=-----END RSA PRIVATE KEY-----`;// 公钥内容，用于加密签名// 使用 openssl rsa -in rsa.private -pubout -out rsa.pub 生成const PUBLIC_KEY = `-----BEGIN PUBLIC KEY-----MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDdAwx2Srt4i9363PL+RK6o/LF58cbAwX9+IVoQGmBvf8jDJZqACkOBwdRo0LSeTQRBhe5HuuFS3VpatFIoghq069RfeQfOCxH+qzNqYQ+nI5Er3+FK9rZFqfbWjZt7GxSfCjZkcikC1z2mgetleUMow0Pi7SuV0PadbqYt4cC16QIDAQAB-----END PUBLIC KEY-----`;// 加密的信息const MESSAGE = { message: 'Hello World' };// 信息散列方式const MESSAGE_HASH_TYPE = 'sha256';// 应用名称，长度不定，双方知道即可const APP_NAME = 'testApp';// Salt，盐，双方约定增加破解难度的随机数，为 32 字节长度const SALT = 'd41d8cd98f00b204e9800998ecf8427e';// 签名超时时间，按秒计算，const TIMEOUT = 10;// 签名类型const SIGNATURE_TYPE = 'RSA-SHA256';// 签名输出类型// see https://nodejs.org/dist/latest-v7.x/docs/api/crypto.html#crypto_sign_sign_private_key_output_formatconst SIGNATURE_OUTPUT_TYPE = 'base64';/** * 签名函数 *  * @param {privateKey} string 加密用私钥 * @param {appName} string 加密内容 * @param {salt} string 盐 * @param {message} string | object | array 消息内容 * @returns string 加密后的签名字符串 */function sign(privateKey, appName, salt, message = '') {  // 当前时间的 unix 时间戳  const timestamp = parseInt(new Date().getTime()/1000);  // 生成信息散列  const json = JSON.stringify(message);  const hash = crypto.createHash(MESSAGE_HASH_TYPE);  hash.update(json);  const messageHash = hash.digest('hex');  // 生成加密的字符串  const signStr = appName + timestamp + salt + messageHash;  console.log(`String will sign is - ${signStr}`);  // 加密内容  const signer = crypto.createSign(SIGNATURE_TYPE); // 默认通过 RSA-SHA256 对称算法进行加密  signer.update(signStr);  return signer.sign(privateKey, SIGNATURE_OUTPUT_TYPE)}/** * 签名验证函数 * 原理是根据加密后的签名，倒推10秒钟，其中一次的签名如果对上了，就算验证成功。 * 中途最多可能需要生成 10 次加密后的签名，进行对比。 *  * @param {publicKey} string 解密用公钥 * @param {privateKey} string 生成加密用私钥 * @param {appName} string 应用名称 * @param {salt} string 盐 * @param {signature} string 用于验证的签名 * @param {message} string | object | array 消息内容 * @returns boolean 成功为真，失败为假 */function validate(publicKey, privateKey, appName, salt, signature, message) {  // 获取当前时间戳  const now = parseInt(new Date().getTime()/1000);  // 生成信息散列  const json = JSON.stringify(message);  const hash = crypto.createHash(MESSAGE_HASH_TYPE);  hash.update(json);  const messageHash = hash.digest('hex');  // 从当前时间戳往前推 10 秒，检查签名字符串是否合法  let count = 0;  let timestamp = now;  while(count < TIMEOUT) {    const signStr = appName + timestamp + salt + messageHash;    // 生成签名    const signer = crypto.createSign(SIGNATURE_TYPE);    signer.update(signStr);    const newSignature = signer.sign(privateKey, SIGNATURE_OUTPUT_TYPE);    // 首先检查签名是否正确    const verifier = crypto.createVerify(SIGNATURE_TYPE);    verifier.update(signStr);    const result = verifier.verify(publicKey, newSignature, SIGNATURE_OUTPUT_TYPE)    // 签名正确后，检查加密后内容是否一致    if (result) {      // Signature correct      if (newSignature === signature) {        // Content correct        return true      }    }    count += 1;    timestamp -=1;  }  return false}const signature = sign(PRIVATE_KEY, APP_NAME, SALT, MESSAGE);console.log(`Signature is - ${signature}`);// 2 秒内签名可用，应该返回 truesetTimeout(() => {  const result = validate(PUBLIC_KEY, PRIVATE_KEY, APP_NAME, SALT, signature, MESSAGE);  console.log(`Validate should be correct in 2 seconds - ${result}`);}, 2000);// 10 秒后签名失效，应该返回 falsesetTimeout(() => {  const result = validate(PUBLIC_KEY, PRIVATE_KEY, APP_NAME, SALT, signature, MESSAGE);  console.log(`Validate should be incorrect after 10 seconds - ${result}`);}, 10000);

执行结果如下：

$ node ./sign.js String will sign is - testApp1484759320d41d8cd98f00b204e9800998ecf8427ea5759911f3c834348667ca417f6c8bb4484b58f9af27e91e7c95b208e43761faSignature is - uDQgfC2oy+4vndp5/PZA+6vnp4q6iicTFIHDVh6gJZ5Ufkd0/c75Oj3xK/jcKthAOkbNnd3A+CcVzo6aFdKmtPAmsR71ZgoVpJ+5g+kAzz5Gruzt499i9IYxhTQKK5Vo2/swF02n6ShOwWvwVeERUfzzYT9AIuUNhmQJD3+egm8=Validate should be correct in 2 seconds - trueValidate should be incorrect after 10 seconds - false

可以看到该文本被序列化成 testApp1484759320d41d8cd98f00b... 这样的字符串，进而加密成了一串不可识别的代码，接收方拿到这串代码之后即可验证数据的真实性，当超时时则验证失效，这样做还有个好处是将数据失效的时间交由接收方决定，消息发送方只需要增加签名即可。

这段代码只是阐述一个思考过程，并未充分优化，其实可以异步化将每次验证过程放入消息队列中执行。

欢迎交流。;-)

开发目标

我们很清楚 ES6 只是 ES5 的扩展，尽管 Chrome 等浏览器已经率先实现了部分 ES6 功能，但依然需要通过 Babel 进行编译，才能对旧版的浏览器提供支持，其实我个人觉得它除了解决部分开发效率，对于 Javascript 弱类型的实质没有任何改进，从产品质量保证而言，Babel 提供了编译时的语法检查，但是能力仅限于检查未定义变量，而浏览器中直接运行的 ES6 语法，和 Javascript 一样是纯粹的动态语言，最基本的检查能力都不具备。

回到 2014 年，那是个 ES6 语法还未成型的年代，当时有句话叫做“动态语言一时爽，重构时候火葬场”，各大厂商已经认识到了 Javascript 的动态特性无法支撑大型项目的开发，纷纷提出了自己的解决方案，例如 Google Dart、Facebook flow.js 以及本文要介绍的 Microsoft Typescript。

笔者认为，Typescript 是最合适的解决方案，它很简单地为 Javascript 赋予了单个对象赋予了类型、对象赋予了 interface、为目前现有的 Javascript 库赋予了 Declaration File 使他们全部都获得了静态的类型系统，与 ES6 语法基本兼容，比重新设计整个语言的 Dart 更轻，但比 flow.js 更重，配合官方免费的、跨平台的 VisualStudio Code 更是将整个开发生态打造得无可挑剔（另外说一句这个编辑器也是 Typescript 开发，基于 Electron 的 Web 应用）。

一个简单的范例

我们可以通过 tnpm install -g ts-node 来体验 typescript，范例代码是一个很常见的场景，做数据运算的时候，经常会有数据类型不对的情况，Typescript 对于直接的数据操作并没有类型检查，但当生成一个函数，并且对参数赋予类型时，便会在编译时进行类型检查，对于不符合类型要求的地方，会直接抛出错误，中止编译过程，同时我们还可以看到，它对 Javascript 内置的函数都已经做了基本的类型声明，parseInt(value) 后会是一个 number，符合了函数的入参类型要求，便正确输出返回值。

是否有一种 Java 的既视感？通过静态类型声明，就具备了和 Java 一样的开发大型应用的能力，

基本配置

Typescript 比较好的地方是，编译器本身只有 typescript 一个包，通过 tnpm install -g typscript 将会安装 v2.0.10 稳定版（截止发稿时），安装之后，系统中将会多出一个 tsc 命令，它是 Typescript 的编译器。

可以写一个很简单的代码，进行编译测试。

let value: string;value = 'Hello world';const printStr = (str: string) => {  console.log(str);}printStr(value);

保存为 helloworld.ts，然后直接执行 tsc helloworld.ts，将会输出成默认的 ES3 javascript

var value;value = 'Hello world';var printStr = function (str) {  console.log(str);};printStr(value);

Typescript 是具备直接输出 ES6 能力的，只需要在编译时加上 -t es6 参数，便可以输出 ES6 的目标文件，从输出的 js 文件和 ts 文件对比，就会发现 ts 只是比 js 多了个参数类型定义。

let value;value = 'Hello world';const printStr = (str) => {  console.log(str);};printStr(value);

编译参数可以直接在命令行后面加上，更多参数可以参考编译选项，也可以通过 tsconfig.json 直接定义，首先可以使用 tsc --init 生成初始化的配置文件，我这里加了 files 用于定义输入的源代码。

{  "compilerOptions": {    "module": "commonjs",    "target": "es5",    "noImplicitAny": false,    "sourceMap": false  },  "files": [    "helloworld.ts"  ]}

然后直接使用 tsc 就可以进行编译了，更多编译参数，请参考 tsconfig.json 文档

需要特别说明的是以下几个参数

配合 webpack

Typescript + Webpack 使用非常简单，和 Babel 非常类似，只需要加上 ts-loader 或者 awesome-typescript-loader 这两个 loader 各有千秋，其实目前 Typescript 直出 ES5 已经非常成熟，用 ts-loader 即可，如果有需要使用 Babel 进行 ES6 到 ES3 编译的可以使用 awesome-typescript-loader 据说有更好的性能和特性。

这里有一份 webpack 范例配置文件。

语法 Linter

Linter 的作用是保证多人开发时的语法的一致性，它可以在编译前进行语法检查，找出不合规的地方，并给出 Warning，这些不合规的地方未必会影响代码运行结果，但是当多人开发时，保持一致的代码风格还是很有必要的。

和 Javascript 一样，Typescript 也有 linter，叫做 tslint，它提供了语法检查和开发指导。

使用 tnpm install -g tslint 之后，会增加 tslint 命令，可以使用 tslint --init 生成 tslint 的默认配置文件，我们用它来检查一下刚出的 helloworld.ts。

» tslint helloworld.ts helloworld.ts[2, 9]: ' should be "helloworld.ts[5, 2]: Missing semicolon

很明显，它提示了第二行的单引号需要改为双引号，同时第五行少了一个分号。

实际开发之中是不会使用默认的宽松配置的，tslint 已经提供了大量参考配置，我们一般使用“推荐”配置，可以参考 tslint.json 它从代码的考虑已经做了大量优化，可以作为项目中的推荐方案。

语法简介

Typescript 语法与 ES6 语法基本一致，const、let 箭头函数可以直接使用，比较出色的地方是它不需要增加插件便可以实现一些高级语法编译，例如 async 和 await，相对于 Babel 我感觉 Typescript 编译出的代码更佳简单干净，可读性高。

和 ES6 不一样的地方，是它增加了类型系统，这又主要分以下几种类型定义方式。

变量类型系统

在 Typescript 中，声明变量时如果直接赋值，则会使用自动类型判断固定该变量的类型，例如：

const foo = 123; // numberconst bar = 'abc'; // string

如果需要声明一个变量，但不赋值，就必须给它声明一个类型，当后期使用类型不符合时会抛出错误。

let foo: number;foo = 123; // Okfoo = 'abc'; // Type 'string' is not assignable to type 'number'. (2322)

Typescript 的基本类型主要有：

更多范例，请参考官方基础类型文档。

对象 Object

对于 Object 的类型定义，主要通过 interface 关键字进行定义，和基本变量定义类似，interface 也非常简单。

interface IHelloWorld {  hello: string;  world: number;  foobar?: void; // Optional property}const helloWorld: IHelloWorld {  hello: 'Hello',  world: 123,}console.log(JSON.stringify(helloWorld));helloWorld.foobar = null;console.log(JSON.stringify(helloWorld));helloWorld.test = 123;console.log(JSON.stringify(helloWorld));

直接使用 ts-node 运行会发现编译不过，抛出了错误

test.ts(17,12): error TS2339: Property 'test' does not exist on type 'IHelloWorld'.

是因为在最后我们给 helloWorld 赋予了一个 interface IHelloWorld 中不存在的 test property，把它删掉就可以正常编译运行了，由此可见 Typescript 的严谨。

类 property 类型声明、方法私有性声明

和 ES6 一样，Typescript 也提供了 class 关键字用于声明累，而 property 类型声明借鉴了初始化值的语法，直接在 constructor() 之上，像初始化变量一样进行类型赋予即可。

class Foobar {  private str: string; // this.str type  public constructor(str) {    this.str = str;  }  public printStr() {    console.log(this.str);  }}const foo = new Foobar('Hello world');foo.printStr();

这里还能对方法的私有性进行定义，当不慎掉用到 private 方法时，编译器就会报出错误阻止编译过程，有效保护私有方法。

第三方库接口类型定义 Declaration File

Typescript 因为其特点，所以对第三方库提供的接口也有强类型的需求，但是老的第三方库往往都是使用 Javascript 进行开发，并没有声明接口类型，微软采用了一个取巧的办法，给第三方库增加了一个 .d.ts 的类型声明文件。

社区里已经有了绝大多数常用库的类型声明文件，保存在 DefinitelyTyped 仓库里，可以直接使用 tnpm 的 @types private repo 进行安装，例如 tnpm install @types/react-bootstrap 安装 react-bootstrap

类型声明文件还有一个好处是它在声明类型的同时，还可以对函数的用法进行说明，这样开发起来不用查看源代码或者官方文档，在 IDE 里就能了解方法的功能。

但遇到比较冷门的第三方库，没有 d.ts 文件提供时，直接 import 它会提示找不到 module，对于比较小的第三方库，建议自己用 Typescript 重写，也可以自己开发 d.ts 文件进行类型定义，Typescript 2.0 对 d.ts 文件进行了大量简化，具体开发内容有点大，可以参考 官方文档，未来或许会单独写一篇《Typescript Declaration File 开发指南》。

成功案例

因为 Typescript 静态类型的特性，各大公司都在积极使用 Typescript 进行项目开发。

1. Google 的 Angular 2
2. 蚂蚁金服的 Ant.design
3. Teambition

目前我们组已经在内部使用 Typescript 进行项目开发，目前主要成果有：

1. vincenzheng 的微信小程序脚手架
2. xqkuang 的 react-redux 脚手架
3. xqkuang 的 NodeJS 服务器框架（进行中）
4. xqkuang 的腾讯指数统计埋点

这个用 React + Redux 因为没有先例，而它又有自己内部的，不对外暴露的 Store，导致整个中秋节都在思考这个问题

先来看一下最终实现的效果（请忽略还没有开始写样式。。。）。

URL 是什么？

一个典型的 URL: http://example.com/user/xqkuang/articles/add?kmref=km_header&editor=md ，其中包含了：

1. 协议 Protocol- http:// 协议
2. 服务器域名 Host - km.oa.com
3. 访问网页路径，学名 路由 Router - /user/xqkuang/articles/add -这是网页路由，还有一种单页应用专有的通过 hash # 符号开头确定的路由，因为单页应用只有一个 HTML 文件，当没办法做 nginx tryfile 的时候 hashHistory 也是个 workaround。
4. 参数 Query，问号后面的字符串，用于给路由的网页确定展示的方式 - ?kmref=km_header&editor=md

其中记录状态，主要依靠 路由 确定当前显示哪个网页，参数 确定那个网页怎么进行展示。

路由和参数如何设计？

设计原则其实非常简单，一个网页从一开始就必须确定的内容，就放到路由里面，例如上面的例子，意思非常明显，就是 /用户/xqkuang/文章/添加 把主谓宾都准备妥当了，谁在哪儿要干什么都很清楚，这些参数都不能少（这个例子其实不是很好，/user/xqkuang可以通过 session 确定，而无需写到 URL 里），如果把这个网页拷贝给另外一个人打开，也会是相同的页面。

而可变的内容，就放到参数里，例如这里的 &编辑器=md 就表明了要用 markdown 而不是 html 编辑器去写文章，如果这里发生变化，那网页的内容也会发生变化，它并不用去描述具体做什么，而是锦上添花似地说明怎么去做，如果没有这些参数，并不影响网页的具体行为和它要做的事情，网页也会以一个默认的参数去达到目标。

服务器端网页和单页应用在处理路由和参数时的异同

服务器端渲染处理路由和参数其实非常简单，因为服务器端直接承接来自浏览器完整的 HTTP 请求，整个 URL 都 直接暴露与 Web service 可见范围之内，服务器端网页拿到请求后，可以根据路由选择合适的 HTML 模板文件，根据参数去判断各种条件，读取数据库并且生成页面，是个很平滑的过程。

而单页应用不同，它从服务器那里获取获取的实际只有一个 Javascript 文件具备处理能力（该文件其实通常放在没有任何处理能力的 CDN 上），路由和参数都是由该 Javascript 进行处理，路由和参数虽然也都传递给了后端服务器，但其实后端根本不处理，对于单页应用的后端服务器而言，除了数据接口服务，它的功能只是生成一个引用了 CDN 上 Javascript 文件的 HTML 字符串给浏览器，Javascript 需要自行根据路由选择合适的前端模板，根据参数去生成 Ajax 数据请求，获取到数据后再在浏览器中显示。

还有一个很重要的不同点，和服务器渲染的网页不同，单页应用通常是通过 window.history.pushState() 方法做到无刷新切换页面的，虽然在页面中点击链接跳转，其实并没有发起新的网页请求到服务器，而全部被 Javascript 捕获，并进行内部根据链接地址进行页面重新渲染，所以每次 URL 的状态也需要随时进行更新。

React + Redux 方案处理路由需要的两个库

从这里开始就需要你有 React + Redux 开发经验了。。。

React 本身只是个 View，所以需要其它的库进行扩展，以方便在应用中使用路由、参数处理等功能。

1. react-router - 路由库

https://github.com/ReactTraining/react-router

这已经是 React 应用标准组件之一，截稿时最新稳定版本是 2.8.x，最新开发版本的 React router 4.0 alpha 将会有很大改变（事实上这个库每次升级看起来都像新的路由库），具体写法请参考官方文档，特别需要提到的是，它在 v2.4 之后提供了 withRouter() 的高阶组件，为 Component 增加了 props.router 方法， 可以通过它进行页面路由、参数的跳转切换，后面会继续提到它。

2. react-router-redux - 将 react-router 的状态映射到 redux store 中

https://github.com/reactjs/react-router-redux

这个库本来只是一个个人开发的小作品，但现在也被 Facebook 收入到 reactjs git 库之下，它的作用是将当前 URL 的路由和状态信息，跟 Store 进行同步，放到 props.routing 里，里面有类似 path、query 那样的属性，这样 Component 可以很方便的查询到当前的 URL 信息。

PS: React router 4.0 后将会提供一个单独的 props.location 来支持相同功能，这个库到时可能会被废弃。

思考路程和 Redux 的限制

在 React Redux 应用中，所有的数据初始化、保存都是在 Redux 中的，经过特别细致的 Component 拆分，目前我所开发应用已经不再使用 React state，而全部使用 mapStateToProps() 方法把所有的 Redux state 转换为 React props 在 Component 间传递数据，这样整个结构非常简单，业务逻辑全部放到 Redux 中，通过 dispatch action 获取需要的数据后，触发 reducer 整理成 Component 所需要的数据，Component 唯一要做的事情，就是根据数据进行重新渲染，类似表格 Component 也是由 Reducer 直出表格行数据进行绘制，数据层与视图层完全分离，这样的优势无疑是很大的，Component 不但不再需要传统网页那样的操作 DOM，甚至不需要和未拆分完全 React 应用那样进行各种是否需要重新渲染的判断，而且特别方便进行单元测试。

Redux 的数据初始化，一般放在 reducer 中，它有两个参数：

1. state - 指向当前 Store 里的 state 信息，第一次 Store 为空时初始化 initialState 数据也在这里声明。
2. action - dispatch 过来的 action 信息，或者是异步 action 返回来的数据。

实际的业务流程是这样的，分两部分：

一、当网页打开时：

从 URL 获取参数 -> 生成 Action 的初始化参数 -> 根据初始化参数生成 ajax 参数 -> 发起数据请求 -> 异步回调将数据传递给 reducer -> reducer 生成 Component 所需要的数据进行渲染

二、当在页面跳转或者选项框 Component 发生变化时:

选项框发生变化-> 生成新的参数 dispatch action -> 根据初始化参数生成 ajax 参数 -> 发起数据请求 -> 异步回调将数据传递给 reducer -> reducer 生成 Component 所需要的数据进行渲染 -> 更新 URL 中的参数字段

依然使用 Redux 去同步数据相对会让视图更新更加容易，因为需要通过它对数据进行修改触发重新渲染机制，但是这样的方案会出现有 Redux Store 和 URL Store 两个存储数据的地方。

最初的想法，是希望能找到一个办法，把 URL 参数 Query 和 Redux Store 里同步起来，但是 Dan 大神认为通过 React Router 进行跳转已经足够。而且在实际的探索中，因为那时 LOCATION_CHANGE action 尚未触发，发现 react-router-redux 的 props.routing 并不能在页面加载完第一次初始化时使用，整个 props 都是空值。同时 reducer 的第一个 state 参数在应用初始化之后不可修改，这给最初的想法带来了很深的困扰。

最终的解决方案

既然不能在应用运行时修改 reducer 的 state 初始化参数，那就在应用初始化时获取一下 URL 里的参数，进行 state 参数初始化好了，虽然没有用上 react-router-redux 的 props.routing 进行参数获取，多余做了一步，但是起码能先解决问题。

监听 history 变动

首先，我这儿先做了一步，在入口代码中，监听 react-router 的 history 改变事件，将路由状态信息放到了 window 全局中（这个确实有点脏，不过路由信息我这儿别的地方也要用，放在这里方便一些）。

/* Initial history */export const history = syncHistoryWithStore(  reactRouter[config.historyBackend], store)// Binding location to window for reducer initialStatehistory.listen(location => {  window.reactLocation = location;});

应用初始化时从 URL 获取参数

然后在工具类中加入 getUrlQuery() 方法，用于获取指定的 URL 参数，还有一个 getUrlQueryTarget() 方法，用于从数据数组中提取指定的对象，我这儿的 action 都是传递对象，这样当 URL 参数不对时（比如被用户篡改了），也可以恢复成默认参数。

可以看到 getUrlQuery() 方法首先从刚才定义的 window.reactLocation 中获取参数，第一次初始化时它不存在，才去直接判断 window.location 中获取实际的参数值的，这里还用到了 qs 库进行 URL 参数解析。

import qs from 'qs';/* * Get url params */export const getUrlQuery = key => {  if (window.reactLocation) {    return window.reactLocation.query[key];  }  let queryStr = ''  if (config.historyBackend === 'hashHistory') {    queryStr = window.location.hash.split('?')[1];  } else if (config.historyBackend === 'browserHistory') {    queryStr = window.location.search.substring(1);  }  const query = qs.parse(queryStr);  return query[key]}/* * Get url query specific object */export const getUrlQueryTarget = (key, collection) => {  const query = getUrlQuery(key);  const targets = collection.filter(x => x.key === query);  if (!targets.length) {    console.error(`Target was not found for query key; ${key}`);    return null  }  return targets[0]}

Reducer 初始化时需要通过 getUrlQueryTarget() 方法，从 URL 里获取初始化参数，并且监听 LOCATION_CHANGE action，当路由发生改变时，处理好 Component 需要的数据并且返回给 Component。

import { LOCATION_CHANGE } from 'react-router-redux';import { INTERNET_PLUS_KINDS } from '../constants';const kindInitialState = {  kinds: INTERNET_PLUS_KINDS,  kind: getUrlQueryTarget('kind', INTERNET_PLUS_KINDS) || INTERNET_PLUS_KINDS[0]}export const internetPlusKindReducer = (state = kindInitialState, action) => {  switch (action.type) {    case LOCATION_CHANGE: {      const kind = INTERNET_PLUS_KINDS.filter(        x => x.key === action.payload.query.kind      )[0];      return {        kinds: INTERNET_PLUS_KINDS,        kind: kind || INTERNET_PLUS_KINDS[0]      }    }    default:      return state  }}

同样的，在另外一个负责 Ajax 请求的容器 Component 里，也需要 connect 到 internetPlusKindReducer，当接收到新的 kind 参数时，通过 componentWillReceiveProps(nextProps) 方法 dispatch action.

之所以把请求放在容器 Component 里，是因为这些组件都是共享一个来自 fetchInternetPlusProvincesData action 的数据，但是会经过 reducer 处理成各自不同需要的数据，所以触发放在容器里。所有子 Component 都无需从父 Container 的 props 里获取参数，而是对接各自的 Reducer 直接获取数据，这样其实就解耦了数据层和视图层。

import React, { Component, PropTypes } from 'react';import { connect } from 'react-redux'import Kind from './kind';import Content from './content';import { fetchInternetPlusProvincesData } from '../../actions/internet-plus';export class Container extends Component {  static propTypes = {    fetchInternetPlusProvincesData: PropTypes.func,    kind: PropTypes.object,  }  componentDidMount () {    const { fetchInternetPlusProvincesData, kind } = this.props;    fetchInternetPlusProvincesData({ kind });  }  componentWillReceiveProps (nextProps) {    const { fetchInternetPlusProvincesData } = this.props;const { kind } = nextProps;    fetchInternetPlusProvincesData({ kind });  }  render () {    return (  <div>        <Kind className="internet-plus-kind" /><Content />  </div>    );  }}// State to props for connect argumentexport const mapStateToProps = (state) => {  return {    kind: state.internetPlusKindlReducer.kind  };};// Dispatch to props for connect argumentconst mapDispatchToProps = {  fetchInternetPlusProvincesData};export default connect(mapStateToProps, mapDispatchToProps)(Container);

当选项框发生改变时，直接改变路由参数。

流程和之前设计时发生了一点点变化，变成了直接改变 URL 参数，然后触发 LOCATION_CAHNGE，reducer 接收到之后整理数据，到容器 Component 触发 Ajax call，整理的数据再返回给容器和选项框组件。

选项框发生变化-> 直接改变路由参数触发 LOCATION_CHANGE -> Reducer 接受到之后根据参数整理新的 Ajax 参数 -> 发起数据请求 -> 异步回调将数据传递给 reducer -> reducer 生成 Component 所需要的数据进行渲染

import React, { Component, PropTypes } from 'react';import { connect } from 'react-redux'import { withRouter } from 'react-router';import { DropdownButton, MenuItem } from 'react-bootstrap';import { changeQuery } from '../../utils';export class InternetPlusChartKind extends Component {  static propTypes = {    router: PropTypes.object,    className: PropTypes.string,    kinds: PropTypes.array,    kind: PropTypes.object  }  changeKindHandle (eventKey) {    const { router } = this.props;    changeQuery(router, 'kind', eventKey);  }  render () {    const { className, kinds, kind } = this.props;    return (      <div className={ className }>        <DropdownButton          id="internet-plus-kind"          onSelect={ eventKey => { this.changeKindHandle(eventKey); } }          bsStyle={ 'primary' }          title={ kind.name }>          {            kinds.map((d) => {              return (                <MenuItem key={ d.key } eventKey={ d.key }>  { d.name }</MenuItem>              );            })          }        </DropdownButton>      </div>    );  }}// State to props for connect argumentexport const mapStateToProps = (state) => {  return {    kinds: state.internetPlusKindReducer.kinds,    kind: state.internetPlusKindReducer.kind  };};export default connect(mapStateToProps)(withRouter(InternetPlusChartKind));

其实我有尝试过保留选项框组件的单独的 change kind action dispatching，不在 Reducer 中监听 LOCATION_CHANGE，但是发现那样会导致浏览器的前进后退按钮失效，最终改成了这样的方案。

这个方案简单、干脆、明了，以上都是核心代码，思路仅供参考，希望能给大家提供帮助。

现代前端开发的特点

现代前端应用越来越复杂，越来越像桌面和移动端的原生应用，这就要求现代前端需要具备一些原生应用的能力，如以下：

1. 具备复杂交互的处理能力 - 什么是复杂的交互？当用户发生一次点击行为时，可能需要同时刷新多个界面元素的状态，在这种情况下，就要加强界面元素之间的通讯能力。
2. 良好的工程化和团队协作开发能力 - 随着项目越来越大，代码复杂度增加，传统的前端开发三驾马车（HTML、CSS、Javascript）难以为继，如何组织架构好前端工程，促进团队协作就成了重点。
3. 可被自动化测试 - 传统的前端开发是非常难以测试的，一是因为从开发模型上就没为自动化测试考虑过，但是项目复杂度的增加，导致版本迭代时回归性 Bug 越来越多，就需要有更好的方案来解决质量问题。

现代前端设计模式

数据视图双向绑定 MVVM

前因

传统的前端开发都是直接通过 Javascript 操作数据与 DOM，例如以下的代码：

$('#button').click(function() {  $.getJSON('http://url.com', function(res) {     $('#label').val(res.value);  });}

短短五行覆盖了点击事件处理、线上数据抓取、界面更新三步，这样的开发适合小型或者简单的页面，但是在开发复杂页面时，这样混杂在一起的代码很容易碰到数据与视图代码难以复用的情况，因为都在一起，也无法进行有效的单元测试。

经过了之前传统开发模式的洗涤之后，有一些开发者开始思考，如何将视图与数据分开，于是借鉴后端的 MVC 开发模型，将前端也进行了拆分，其中比较典型的框架是 Backbone。

但和后端应用的数据库数据不同，这里的数据是通过接口从后端获取的数据；View 视图层，只负责响应页面内的交互事件；Controller 控制器层，负责数据与视图层、视图与视图的通讯。

类似如下：

class Worker extends Controller {  route () {    const view = new View();    view.render().appendTo('#root');    const model = new Model();    model.fetch(function(res) {      view.renderData(res);    }  }}

但是从这里我们可以看到，实际上 Controller 的工作依然是同步视图层和数据层，在适当的时候重绘页面，但这样有两个问题：

1. 数据发生改变时，视图层肯定要发生改变，这一步其实可以让它自动化，就能减少开发者的重复代码。
2. 数据发生改变时，整个页面都需要全部重新绘制，而我们知道 DOM 重绘的开销是非常大的，而且它是一个同步的过程，会造成浏览器线程阻塞，导致用户无法操作。

后果：数据视图双向绑定的 MVVM

开发这在经过了数据和视图之间大量的同步工作后，Reactive 式开发模式在移动端开发先流行起来，它的实现就是 MVVM，它通过 MV（Model-View）层替换了之前的 Controller 层，在 Model 和 View 之间搭建了一个桥梁，当数据发生改变时自动将数据的改变同步到界面上，而无需再有人工操作。

这样大大提高了整体开发效率，同时有效的拆分让可测试性大大提高，只需要测试界面组件对用户行为的响应是否正常，以及数据输入参数后的输出是否符合预期即可。

第一个问题：Javascript 如何知道数据发生改变？

在 ES5 规范中，提供了一个 Object.defineProperty() 方法，它为监听对象属性（Property）改变提供了可能。

它给 Javascript Object 提供了设置 getter 和 setter 的可能，setter 和 getter 是指当给对象属性添加一个获取和改变的监听回调函数，当对对象属性进行操作时，回调函数会自动执行。

例如（代码来自 Object.defineProperty()）：

function Archiver() {  var temperature = null;  var archive = [];  Object.defineProperty(this, 'temperature', {    get: function() {      console.log('get!');      return temperature;    },    set: function(value) {      temperature = value;      archive.push({ val: temperature });    }  });  this.getArchive = function() { return archive; };}var arc = new Archiver();arc.temperature; // 'get!'arc.temperature = 11;arc.temperature = 13;arc.getArchive(); // [{ val: 11 }, { val: 13 }]

第二个问题：部分数据改变时，如何提高视图更新速度？

再次强调，DOM 更新是非常耗时的，Javascript 本身的运算速度非常快，但是一旦开始更新 DOM 就全部慢下来了。所以 MVVM 都采用了更加先进的方法来更新视图。

1. 进行和原始数据的数据对比，缩小更新范围。
2. 普遍采用虚拟 DOM（Virtual DOM）来处理数据更新。

以 React JSX 为例，来描述一下它的虚拟 DOM 如何生成的，首先，JSX 的写法与 HTML 并无二致：

import React from 'react';const HelloComponent = ({ name }) => {  return (    <div className="hello">      Hello, { name }.    </div>  )}React.render(<HelloComponent name="XQ" />, '#root');

经过 Babel 编译之后，原有的 XML 结构会改成 React.createElement() 方法。

'use strict';var _react = require('react');var _react2 = _interopRequireDefault(_react);function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }var HelloComponent = function HelloComponent(_ref) {  var name = _ref.name;  return _react2.default.createElement(    'div',    { className: "hello" },    'Hello, ',    name,    '.'  );};_react2.default.render(_react2.default.createElement(HelloComponent, { name: 'XQ' }), '#root');

React.createElement() 做了如下几件事情，首先把 JSX 改成类似如下的数据结构，其次，对监听该数据中 name 参数的改变。

{tagName: "div",properties: {className: "hello"}children: [{text: "Hello, "},{text: name},{text: "."}]}

然后根据该数据结构中的每一个 Object 都生成实际的 DOM，并且缓存起来，当数据发生改变时就可以直接找到对应的 DOM 更新界面。

当然 React 还做了大量优化，有更好的数据对比算法，而且当数据改变时不是立即更新界面，而是积累到一起，等主线程空闲下来时，一起批量更新等等。

前端资源组件化 Web Component

这里说的不是 W3C 基于 Shadow DOM 的 Web Components 标准，那个标准目前在浏览器支持不完善下暂时不能投入实际使用中。

如前所说，HTML 已经被 Javascript 化，从写页面改为写组件了，但是前端三驾马车里，还有一个 CSS，还有一堆静态资源（例如图片、字体、声音），它们的一些特点让它们难以被组件化。

1. 全局性 - 这些资源直接影响页面全局，不像 Javascript 那样具备命名空间的特性，CSS 的样式一写就会直接影响到整个网页。
2. 难以维护 - 大量散乱的 CSS 和静态资源经过长时间版本迭代后，难以区分哪些资源归属于哪些页面，通常采取的办法是置之不理，但是这样时间一长会导致整个工程很大，冗余代码过多。

解决方案：Webpack

Webpack 是于 2012 年出现的一套前端打包方案，虽然之前出现过其它的组件加载方案，例如 require.js、sea.js、browserify 等等，但是它是第一个能够把静态资源也打包进来的解决方案。

它的神器之处在于它有一堆 Loader，通过指定扩展名和 Loader 的对应关系，便能将它们打包整合进入前端组件中。

Loader 的配置范例如下：

    loaders: [      {        test: /.*\.json$/,        loader: 'json' // json loader 可以将 JSON 转换为 Javascript      },      {        test: /\.jpe?g$|\.gif$|\.png$|\.svg$|\.eot$|\.woff2?$|\.ttf$|\.wav$|\.mp3$/,        loader: "file" // file loader 将静态资源转换为 base64 整合进入 Javascript      },      {        test: /\.js$/,        loader: 'babel',        exclude: /node_modules/,        include: __dirname // babel loader 将 ES6 代码编译成 ES5，提前使用新特性。      },      {        test: /\.less?$/,        loaders: ['style', 'css', 'less'] // 这三个 loader 将 less 转换为 HTML inline style。      }    ]

如果需要引用图片，不再需要手写 ，而是：

import logoImage from './logo.png'; // Import logo imageimport 'style.less'; // Import styleconst img = document.createElement('img');img.src = logoImage;document.body.appendChild(img);

以脉脉网为例，样式被引用进界面后，会生成一个单独的