苏州：园林里的年味

苏州是第一站。

春节期间的苏州，游客比平时少了不少，反而多了一份难得的安静。拙政园的游廊上挂着红灯笼，倒映在水面里，晃晃悠悠的。

平江路是必去的。老街两侧的店铺大多还开着，卖桂花糕、苏式糖果、手工团扇。买了一盒玫瑰猪油年糕，甜而不腻，带回去当伴手礼刚好。

苏州的早饭值得专门说一说。找了一家老苏州面馆，点了一碗枫镇大肉面。汤是白色的，用猪骨和酒酿吊出来的，鲜得很克制，不抢戏。面条细而有劲，大肉酥烂，筷子一碰就脱骨。这碗面，吃完之后整个上午都是满足的。

虎丘塔在春节期间有灯会，晚上亮起来，塔身的轮廓在夜色里很好看。没有挤进人群，就在远处的桥上看了一会儿，也够了。

淮安：一座被低估的城市

淮安是意外之喜。

很多人去江苏，不会把淮安列进行程。但这座城市有一种别处没有的从容——不赶时髦，不刻意打造网红景点，就是安安静静地过自己的日子。

河下古镇是淮安最值得待的地方。青砖小巷，石板路，巷子里偶尔传来鞭炮声，年味比苏州更浓。镇上有一家做淮扬菜的小馆子，软兜长鱼、平桥豆腐、文思豆腐，每一道都是功夫菜。软兜长鱼是用鳝鱼做的，口感嫩滑，酱汁咸鲜，配着白米饭能吃两碗。

淮安是周恩来的故乡，周恩来纪念馆在春节期间人不多，安静地走了一圈，看了很多历史照片，心里有些沉。

运河边的夜晚很适合散步。灯光打在水面上，对岸是老城区的轮廓，没有什么特别的景点，就是走走，也很好。

西游记主题公园是带小孩的好去处。春节期间有特别的表演，孙悟空、猪八戒、沙僧都穿着节日的服装，表演得很卖力。孩子们看得目不转睛，大人也被逗得哈哈大笑。

常州：恐龙和青果巷

常州是最后一站，也是节奏最轻松的一站。

中华恐龙园是带小孩来的好地方。春节期间有特别的灯光秀，恐龙模型在彩灯里显得格外有气势。孩子们跑来跑去，大人跟在后面，累但是开心。

青果巷是常州的老城区，修缮得很好，没有过度商业化。巷子里有几家老字号，卖大麻糕、芝麻糖、萝卜干。大麻糕是常州特产，外皮酥脆，内馅咸香，趁热吃最好，凉了就差了一截。

天宁寺在春节期间香火很旺。寺庙不大，但香客很多，烟雾缭绕，钟声厚重。在这里待了半个小时，什么都没想，就是站着，听钟声。

总结

春节出行，前两天的行程是最舒适的，因为人少，更容易让人放松下来。

三座城市，各有各的好。如果只能选一座再去一次，我会选淮安。不是因为它最出名，而是因为它最让我意外。

节前规划了很久的行程，最终因为怕人多，怕堵在路上停留在了纸上。

想起以前的自己喜欢热闹，哪里人多就往哪里跑。

年纪大了以后就真的变了，喜欢清净，喜欢人少的地方，最后选择了去九宫山上待了两天。

从武汉出发到九宫山差不多三个小时，盘山公路就占了一个小时。

山路其实没那么难跑，无外乎多给点油，开慢一点。但是不断想超车、占道的司机让上山之路变得如履薄冰。

下午四点多到达，山上的风一吹，心里那口闷气也松了。老婆说：”人好少啊，这不像国庆的景区。”我笑着说：”看来来对了。”或许是那一段山路劝退了大多数人，或许是大家来过一次，就不愿意再折腾第二回。

我们在山顶的小湖边走了一圈。日出和日落，只选一个。我果断放弃了日出——4点半起床，这种事太反人性。反而是日落刚刚好，光线正柔，风也温柔。

随后坐摆渡车来到山顶。山顶的天，层层叠叠。我们坐在石阶上，背靠着背，她靠在我肩上，我拿出手机拍了一张。

“有颗流星，你拍到了吗？”她突然问。我低头一看，真有。流星从夕阳的头顶划过。

那一刻，脑海里突然回响起那首歌：”总会梦见云层之上飞过子午线，分不起是黑夜还是白天。”

假期就这样结束了。没出远门，也没拍什么大片，但我知道，这次的”没去哪里”，好像比去很多地方更让我安静。

项目背景

金融贷款类 H5 应用有几个典型特点：

1. 页面结构高度相似：注册、登录、申请步骤、还款等页面在不同产品线之间大量复用
2. 多地区多品牌：同一套业务逻辑需要支持菲律宾、香港等不同市场，UI 和文案各有差异
3. 安全要求高：请求加密、活体检测、证件上传等功能必不可少

基于这些特点，我们决定用 Monorepo 把所有子应用和共享包统一管理，并在此基础上做一个低代码编辑器，让运营和产品可以快速配置页面。

Monorepo 结构设计

xxx-editor/
├── packages/
│   ├── core/        # 低代码编辑器核心（Designer + Renderer）
│   ├── widgets/     # 基础 UI 组件库（40+ 组件）
│   ├── templates/   # 页面级模板（Login、Register、MePage 等）
│   ├── components/  # 增强型表单组件
│   └── utils/       # 工具函数（HTTP、加密、格式化、缓存、i18n）
├── server/          # 主业务 Next.js 应用
├── ph-life/         # 菲律宾生活服务应用
├── ph-life-website/ # 菲律宾官网
└── max-cash-portal/ # Max Cash 多语言门户

包管理用的是 pnpm workspaces，pnpm-workspace.yaml 配置如下：

packages:
  - "packages/*"
  - "server"
  - "ph-life"
  - "ph-life-website"
  - "max-cash-portal"

各子应用通过 workspace 协议引用内部包，例如：

{
  "dependencies": {
    "@xxx/widgets": "workspace:*",
    "@xxx/utils": "workspace:*"
  }
}

这样改动组件库后，所有子应用都能实时感知，不需要发布 npm 包。

HTTP 层的设计

HTTP 层是整个框架里最复杂的部分之一，封装在 packages/utils/src/http/axios 下。核心是一个 VAxios 类，支持：

• 请求/响应拦截：统一处理 Token 注入、错误码映射
• 请求取消：通过 AxiosCanceler 管理 pending 请求，页面切换时自动取消
• 自动重试：AxiosRetry 对网络抖动场景做指数退避重试
• 请求加密：敏感接口的请求体走 AES 加密

// 创建实例时注入 transform 钩子
const http = createAxios({
  transform: {
    beforeRequestHook(config, options) {
      // 拼接时间戳、加密 body 等
    },
    responseInterceptors(res) {
      // 统一解包 { code, data, msg }
    },
    responseInterceptorsCatch(error) {
      // checkStatus 映射错误码到提示文案
    },
  },
});

Token 刷新用的是经典的”请求队列”方案：刷新期间的所有请求挂起，刷新成功后统一重放。

组件库的 Variant 模式

packages/widgets 里的组件大量使用了 Variant（变体） 模式。以 Card 为例：

Card/
├── Basic/          # 基础卡片
├── VariantOne/     # 贷款产品卡片
├── VariantSecond/  # 还款信息卡片
├── VariantRecord/  # 账单记录卡片
└── VariantSeventh/ # 推广活动卡片

每个 Variant 有独立的 definition.ts（props 类型定义）、styled.ts（样式）和主组件文件，互不干扰。这种结构的好处是：

• 新增变体不影响已有变体，改动范围可控
• Storybook 可以为每个变体单独写 story，方便 QA 验收
• 低代码编辑器可以把每个变体作为独立的”积木块”注册

低代码编辑器核心

packages/core 实现了一个轻量的低代码运行时，主要由三部分组成：

• Designer：拖拽画布，左侧 WidgetPanel 展示可用组件，右侧 SettingPanel 配置属性
• Renderer：根据 JSON Schema 渲染页面，通过 WidgetListRender 递归渲染组件树
• register：组件注册机制，将 widgets 中的组件映射到编辑器可识别的 key

// 注册一个组件
register({
  key: "CardVariantOne",
  component: CardVariantOne,
  defaultProps: { title: "贷款产品", amount: 0 },
});

JSON Schema 的结构大致如下：

{
  "widgets": [
    {
      "key": "CardVariantOne",
      "props": { "title": "快速贷", "amount": 50000 }
    },
    {
      "key": "Button",
      "props": { "text": "立即申请", "type": "primary" }
    }
  ]
}

加密工具的分层设计

packages/utils/src/encrypted 里的加密工具做了比较清晰的分层：

encrypted/
├── implForStorage.ts  # 工厂类，支持 AES / MD5 / SHA256 / SHA512 / Base64
├── standard.ts        # 对外暴露的标准 API
└── index.ts

工厂类用单例模式管理各加密实例，避免重复初始化：

class AesEncryption {
  private static instance: AesEncryption;
  static getInstance(options: AesEncryptionOptions) {
    if (!this.instance) this.instance = new AesEncryption(options);
    return this.instance;
  }
  encrypt(value: string) {
    /* ... */
  }
  decrypt(value: string) {
    /* ... */
  }
}

对外只暴露 encryptByAES、decryptByAES、encryptByMd5 等函数，调用方不需要关心内部实现。

多语言方案

max-cash-portal 是一个多语言门户，用的是 Next.js App Router 的 [lang] 动态路由方案：

app/
└── [lang]/
    ├── layout.tsx   # 根据 lang 加载对应字典
    └── page.tsx

middleware.ts 负责检测用户语言并重定向：

export function middleware(request: NextRequest) {
  const locale = getLocale(request); // 从 Accept-Language 或 cookie 读取
  return NextResponse.redirect(new URL(`/${locale}${pathname}`, request.url));
}

字典文件放在 dictionaries/ 下，按语言分文件，generateStaticParams 在构建时生成所有语言的静态页面。

Storybook 组件文档

packages/stories 是整个组件库的 Storybook 工程，独立作为 @xxx/storybook 包存在，运行在 6006 端口。
这也是我认为架构设计里比较成功的一点，Storybook 和组件库虽然紧密相关，但职责不同，分开管理更清晰并且方便 UI 和 QA 访问而不需要跑整个 Next.js 应用。

配置要点

Storybook 使用的是 @storybook/react-webpack5，在 webpackFinal 里配置了 workspace 包的路径别名，让 stories 可以直接 import 内部包的源码而不是构建产物：

// packages/.storybook/main.js
webpackFinal: async (config) => {
  config.resolve.alias = {
    "@xxx/widgets": path.resolve(__dirname, "../widgets/src"),
    "@xxx/utils": path.resolve(__dirname, "../utils/src"),
    "@xxx/components": path.resolve(__dirname, "../components/src"),
  };
  return config;
};

这样改了组件源码后，Storybook 热更新可以直接生效，不需要先 build 包。

样式方面配置了完整的 Less / Sass / CSS Modules 支持，因为 widgets 里的组件混用了多种样式方案。

Story 的写法

项目里的 story 统一用 StoryFn 模板模式，以 Guide 组件为例：

const Template: StoryFn<GuideProps> = (args) => <Guide {...args} />;

export const Default = Template.bind({});
Default.args = {
  title: "Item List",
  items: [{ imageSrc: "...", itemTitle: "Item 1", description: "..." }],
};

export const CustomStyles = Template.bind({});
CustomStyles.args = {
  // 通过 cssClassnames + cssStyles 注入自定义样式
  cssStyles: `.xxx-guide img { width: 32px; }`,
};

每个组件至少有 Default 和边界场景（如 Empty）两个 story，复杂组件还会有 CustomStyles 等变体，方便 QA 和设计师对照验收。

Form 组件的 story 比较特殊，用了 argTypes 的 control: 'check' 让测试人员在 Storybook 面板上勾选需要展示的表单字段，动态渲染表单，不需要改代码就能验证各种字段组合：

argTypes: {
  fields: {
    control: 'check',
    options: xxx_FORM_FIELDS.map((field) => field.label),
  },
}

启动与构建

# 开发模式
pnpm dev:storybook

# 构建静态站点（可部署到 CDN 供设计师访问）
pnpm build:storybook

小结

整个项目下来，几个体会比较深的点：

1. Monorepo 的收益在中后期才明显：前期搭架子比较费时，但后期多个子应用共享组件和工具函数时，维护成本大幅降低
2. Variant 模式适合业务组件：纯 UI 组件用 props 控制变体就够了，但业务组件的差异往往不只是样式，Variant 模式更清晰
3. 低代码不是银弹：低代码适合结构固定、配置频繁的场景，对于逻辑复杂的页面，还是直接写代码更高效
4. 加密要早规划：加密方案如果后期才加，改动面会很大，最好在 HTTP 层统一处理，业务代码无感知

背景

xxx 系统的接口采用 AES-CBC 加密，请求体、响应体以及真实路径都是密文。打开 Chrome DevTools 的 Network 面板，看到的是这样的内容：

request body:  "U2FsdGVkX1+..."
response body: "U2FsdGVkX1+..."
x_x_path:      "U2FsdGVkX1+..."

每次调试都要手动解密，效率极低。于是我决定写一个 DevTools 插件，把解密过程自动化。

技术方案

整体架构分两层：

• Chrome Extension 层：利用 chrome.devtools.network API 监听网络请求，用 chrome.scripting.executeScript 从页面 localStorage 读取加密密钥（xxxSalt）。
• 前端 UI 层：用 Vue 3 + Element Plus 构建 DevTools 面板，展示解密后的请求列表和响应内容，并支持语法高亮。

xxx-network/
├── manifest.json          # 插件配置
├── devtools.html          # DevTools 入口页
├── devtools.js            # 注册自定义面板
├── xxx-network/         # Vue3 前端项目
│   └── src/
│       ├── util.ts        # AES 解密核心逻辑
│       └── components/
│           └── Main.vue   # 主界面
└── chrome-plugin-xxx-network.sh  # 打包脚本

核心：AES-CBC 解密

加密算法是 AES-CBC + PKCS7 填充，IV 固定为 xxx_mgr_item_a，密钥由 xxxSalt 经过一次解密得到（两层嵌套）。

// util.ts
function getIvAndkey(xxxSalt: string, key: string) {
  return {
    iv: "xxx_mgr_item_a",
    key: decrypt(xxxSalt, { iv: "xxx_mgr_item_a", key }),
  };
}

function decrypt(str: string, { iv, key }: { iv: string; key: string }) {
  if (str.startsWith("{")) return formatJSONString(str); // 未加密，直接解析
  str = str.replace(/"/gi, "");
  const decrypted = CryptoJS.AES.decrypt(str, CryptoJS.enc.Utf8.parse(key), {
    iv: CryptoJS.enc.Utf8.parse(iv),
    padding: CryptoJS.pad.Pkcs7,
    mode: CryptoJS.mode.CBC,
  });
  const result = decrypted.toString(CryptoJS.enc.Utf8).trim();
  if (result.startsWith("{")) return formatJSONString(result);
  return result;
}

generate 函数把一条原始网络请求转换成可读的结构：

export const generate = (network: any, { content, salt }) => {
  const token = network.request.headers.find((h) =>
    ["xxxtoken", "token"].includes(h.name.toLowerCase()),
  );
  const xxPath = network.request.headers.find(
    (h) => h.name.toLowerCase() === "x_x_path",
  );

  const { iv, key } = getIvAndkey(salt, token?.value);

  return {
    status: network.response.status,
    url: network.request.url,
    path: decrypt(xxPath?.value, { iv, key }) || network.request.url, // 真实路径
    params: JSON.stringify(
      decrypt(network.request.postData?.text, { iv, key }),
    ),
    reponseObj: decrypt(content, { iv, key }), // 解密响应体
  };
};

监听网络请求

在 Main.vue 的 onMounted 中，通过 chrome.devtools.network.onRequestFinished 监听请求完成事件，过滤出 /manager 路径下的接口，再用 chrome.scripting.executeScript 注入脚本从页面读取 xxxSalt：

chrome.devtools.network.onRequestFinished.addListener((request) => {
  if (!request.request.url.includes("/manager")) return;

  request.getContent((content) => {
    chrome.tabs.query({ active: true, currentWindow: true }, (tabs) => {
      chrome.scripting
        .executeScript({
          target: { tabId: tabs[0].id },
          function: () => localStorage.getItem("xxxSalt"),
        })
        .then(([{ result: salt }]) => {
          requests.push(generate(request, { salt, content }));
        });
    });
  });
});

UI 界面

面板左侧是请求列表，展示状态码、URL、解密后的真实路径和请求参数；右侧点击 “Response” 后显示格式化的 JSON 响应，通过 Prism.js 做语法高亮（字符串绿色、数字蓝色、布尔值红色）。

操作按钮只有两个，保持简洁：

• Clear All：清空所有请求记录
• Copy Response：复制当前响应内容到剪贴板

构建与安装

# 开发调试
cd xxx-network
npm i && npm run dev

# 打包
npm run build
cd ..
bash ./chrome-plugin-xxx-network.sh

脚本会把 Vite 构建产物、manifest.json、devtools.js 等文件整合到 chrome-xxx-network/ 目录，在 Chrome 的 chrome://extensions/ 页面加载该目录即可。

manifest.json 关键配置：

{
  "manifest_version": 3,
  "permissions": ["tabs", "activeTab", "scripting"],
  "devtools_page": "devtools.html",
  "host_permissions": ["http://localhost/*", "*://*.xxx.com/*"]
}

host_permissions 限定了插件生效的域名，避免对无关站点产生影响。

小结

整个插件的核心思路很清晰：DevTools API 拦截请求 → 从页面上下文读取密钥 → AES 解密 → Vue UI 展示。代码量不大，但解决了实际痛点。

如果你的项目也有类似的接口加密场景，可以参考这个思路，把解密逻辑替换成自己的算法，快速定制一个专属的 DevTools 调试面板。

问题的本质：抢购是 I/O 密集型任务

抢购脚本的核心逻辑大概是这样：

1. 轮询库存接口，等待开售
2. 一旦有货，立刻发起下单请求
3. 并发发多个请求，提高成功率

整个过程 CPU 几乎不干活，大部分时间都在等网络响应。这是典型的 I/O 密集型场景。

Python 的 GIL：多线程的天花板

Python 有一个臭名昭著的东西叫 GIL（Global Interpreter Lock，全局解释器锁）。

它的存在是为了保证 CPython 解释器在同一时刻只有一个线程在执行 Python 字节码，避免内存管理出问题。

import threading
import requests

def buy():
    resp = requests.post("https://maotai.example.com/order", json={"sku": "53度飞天"})
    print(resp.status_code)

threads = [threading.Thread(target=buy) for _ in range(10)]
for t in threads:
    t.start()
for t in threads:
    t.join()

上面这段代码开了 10 个线程，看起来是并发的。但实际上：

• 当一个线程在执行 Python 代码时，其他线程被 GIL 挡在门外
• 只有当线程进入 I/O 等待（比如等网络响应）时，GIL 才会释放，让其他线程有机会运行

所以 Python 的多线程在 I/O 密集型场景下能用，但有额外开销：线程切换、GIL 争抢，都是负担。

asyncio：Python 的正确姿势

对于 I/O 密集型任务，Python 更推荐用 asyncio + aiohttp：

import asyncio
import aiohttp

async def buy(session):
    async with session.post("https://maotai.example.com/order", json={"sku": "53度飞天"}) as resp:
        print(resp.status)

async def main():
    async with aiohttp.ClientSession() as session:
        tasks = [buy(session) for _ in range(10)]
        await asyncio.gather(*tasks)

asyncio.run(main())

asyncio 是单线程的事件循环，没有 GIL 争抢，并发效率更高。但它是协作式调度——你必须在代码里主动 await，否则整个循环会被卡住。

Go 的 goroutine：真正的并发

Go 没有 GIL。它的并发单元是 goroutine，由 Go 运行时调度，而不是操作系统。

package main

import (
    "fmt"
    "net/http"
    "bytes"
    "sync"
)

func buy(wg *sync.WaitGroup) {
    defer wg.Done()
    body := []byte(`{"sku":"53度飞天"}`)
    resp, err := http.Post("https://maotai.example.com/order", "application/json", bytes.NewBuffer(body))
    if err != nil {
        fmt.Println("error:", err)
        return
    }
    fmt.Println(resp.StatusCode)
}

func main() {
    var wg sync.WaitGroup
    for i := 0; i < 10; i++ {
        wg.Add(1)
        go buy(&wg)
    }
    wg.Wait()
}

goroutine 的特点：

• 极轻量：初始栈只有 2KB，可以轻松开几万个
• 抢占式调度：Go 运行时会主动调度 goroutine，不需要你手动 await
• 真正并行：在多核机器上，多个 goroutine 可以同时跑在不同的 CPU 核心上

直接对比

抢购场景下的实际差距

假设你要并发发 100 个请求，每个请求耗时 200ms：

• Python 多线程：线程切换开销 + GIL 争抢，实际并发度受限，总耗时可能在 400~600ms
• Python asyncio：单线程事件循环，理论上接近 200ms，但受限于事件循环本身的调度延迟
• Go goroutine：100 个 goroutine 真正并发，总耗时接近单次请求的 200ms

在抢购这种毫秒必争的场景下，这个差距是实质性的。

结论

• 如果你用 Python 写抢购脚本，用 asyncio + aiohttp，不要用多线程
• 如果你追求极致并发和低延迟，Go 是更合适的选择

当然，抢到茅台还是要靠运气，祝大家都能抢到心仪的茅子。

BEM规范应该是对于我们现在前端组件开发中我觉得是最合适的一套范式了。所以，我在自己的日常工作中也是十分的推崇这样的一套CSS范式。

而自己最近也在看各种ui框架的源码，觉得ele对于这块还是处理的蛮好的，所以拿出来说说。

1. BEM

BEM是什么？

BEM范式我在以前自己的文章中简单的说过，就不再赘述了。

我们来看看饿了么在BEM这块有着怎样的实践。

// element-ui
// config.scss
$namespace: 'el';
$element-separator: '__';
$modifier-separator: '--';
$state-prefix: 'is-';

element在config.scss里面定义了一些基础的配置项目，主要包括四个部分：

1. 整套样式的命名空间，命名空间可以带来不同系统样式的隔离，当然缺点就是我们的样式一定是带有一个namespace的前缀出现
2. B和E之间的连接符
3. E和M之间的连接符
4. 状态的前缀，因为有很多的用户行为而带来的激活这样的效果。在js中我们会说到is和as，一个是类型的判定，一个是类型的模糊，这是多态的特性体现。所以，同理的话，is在css中代表的就是当前元素状态的判定，例如：is-checked（是否被选中）之类等等

2. “B”的定义

@mixin b($block) {
  $B: $namespace+'-'+$block !global;

  .#{$B} {
    @content;
  }
}

ele通过宏b来实现的BEM中B的定义。

这里通过radio来作为假设。最后我们在b中通过!global提升了一个$B: el-radio。这也是改良后的BEM。通过插值语句#{ }生成了.el-radio，然后通过@content向生成的B中导入内容。

导入的内容就是通过调用宏b生成的所有的样式：

// 通过宏b生成的所有样式
@include b(radio) {
  color: $--radio-color;
  font-weight: $--radio-font-weight;
  line-height: 1;
  position: relative;
  cursor: pointer;
  display: inline-block;
  white-space: nowrap;
  outline: none;
  font-size: $--font-size-base;
  @include utils-user-select(none);

  @include when(bordered) {
    padding: $--radio-bordered-padding;
    border-radius: $--border-radius-base;
    border: $--border-base;
    box-sizing: border-box;
    height: $--radio-bordered-height;

    &.is-checked {
      border-color: $--color-primary;
    }

    &.is-disabled {
      cursor: not-allowed;
      border-color: $--border-color-lighter;
    }

    & + .el-radio.is-bordered {
      margin-left: 10px;
    }
  }

  @include m(medium) {
    &.is-bordered {
      padding: $--radio-bordered-medium-padding;
      border-radius: $--button-medium-border-radius;
      height: $--radio-bordered-medium-height;
      .el-radio__label { font-size: $--button-medium-font-size; }
      .el-radio__inner {
        height: $--radio-bordered-medium-input-height;
        width: $--radio-bordered-medium-input-width;
      }
    }
  }
  @include m(small) {
    &.is-bordered {
      padding: $--radio-bordered-small-padding;
      border-radius: $--button-small-border-radius;
      height: $--radio-bordered-small-height;
      .el-radio__label { font-size: $--button-small-font-size; }
      .el-radio__inner {
        height: $--radio-bordered-small-input-height;
        width: $--radio-bordered-small-input-width;
      }
    }
  }
  @include m(mini) {
    &.is-bordered {
      padding: $--radio-bordered-mini-padding;
      border-radius: $--button-mini-border-radius;
      height: $--radio-bordered-mini-height;
      .el-radio__label { font-size: $--button-mini-font-size; }
      .el-radio__inner {
        height: $--radio-bordered-mini-input-height;
        width: $--radio-bordered-mini-input-width;
      }
    }
  }

  & + .el-radio {
    margin-left: 30px;
  }

  @include e(input) {
    white-space: nowrap;
    cursor: pointer;
    outline: none;
    display: inline-block;
    line-height: 1;
    position: relative;
    vertical-align: middle;

    @include when(disabled) {
      .el-radio__inner {
        background-color: $--radio-disabled-input-fill;
        border-color: $--radio-disabled-input-border-color;
        cursor: not-allowed;

        &::after {
          cursor: not-allowed;
          background-color: $--radio-disabled-icon-color;
        }

        & + .el-radio__label {
          cursor: not-allowed;
        }
      }
      &.is-checked {
        .el-radio__inner {
          background-color: $--radio-disabled-checked-input-fill;
          border-color: $--radio-disabled-checked-input-border-color;

          &::after {
            background-color: $--radio-disabled-checked-icon-color;
          }
        }
      }
      & + span.el-radio__label {
        color: $--color-text-placeholder;
        cursor: not-allowed;
      }
    }

    @include when(checked) {
      .el-radio__inner {
        border-color: $--radio-checked-input-border-color;
        background: $--radio-checked-icon-color;

        &::after {
          transform: translate(-50%, -50%) scale(1);
        }
      }

      & + .el-radio__label {
        color: $--radio-checked-text-color;
      }
    }

    @include when(focus) {
      .el-radio__inner {
        border-color: $--radio-input-border-color-hover;
      }
    }
  }

  @include e(inner) {
    border: $--radio-input-border;
    border-radius: $--radio-input-border-radius;
    width: $--radio-input-width;
    height: $--radio-input-height;
    background-color: $--radio-input-fill;
    position: relative;
    cursor: pointer;
    display: inline-block;
    box-sizing: border-box;

    &:hover {
      border-color: $--radio-input-border-color-hover;
    }

    &::after {
      width: 4px;
      height: 4px;
      border-radius: $--radio-input-border-radius;
      background-color: $--color-white;
      content: "";
      position: absolute;
      left: 50%;
      top: 50%;
      transform: translate(-50%, -50%) scale(0);
      transition: transform .15s cubic-bezier(.71,-.46,.88,.6);
    }
  }

  @include e(original) {
    opacity: 0;
    outline: none;
    position: absolute;
    z-index: -1;
    top: 0;
    left: 0;
    right: 0;
    bottom: 0;
    margin: 0;
  }

  &:focus:not(.is-focus):not(:active) { /* 获得焦点时 样式提醒 */
    .el-radio__inner {
      box-shadow: 0 0 2px 2px $--radio-input-border-color-hover;
    }
  }

  @include e(label) {
    font-size: $--radio-font-size;
    padding-left: 10px;
  }
}

3. “E”的定义

完成了B以后，就要处理E了。不过在e中多做了两件事：

1. 通过each完成了”BE”的样式的生成，例如是input，那么$currentSelector就是.el-radio__input
2. 通过函数处理 containsModifier($selector)、containWhenFlag($selector)、containPseudoClass($selector) 三种情况

@mixin e($element) {
  $E: $element !global;
  $selector: &;
  $currentSelector: "";
  @each $unit in $element {
    $currentSelector: #{$currentSelector + "." + $B + $element-separator + $unit + ","};
  }

  @if hitAllSpecialNestRule($selector) {
    @at-root {
      #{$selector} {
        #{$currentSelector} {
          @content;
        }
      }
    }
  } @else {
    @at-root {
      #{$currentSelector} {
        @content;
      }
    }
  }
}

4. “M”的定义

最后是m的生成，基本上原理都和前面说到的是一样的了。

例如：el-radio--medium，用来描述radio的size属性。那么$currentSelector就是.el-radio--medium。

@mixin m($modifier) {
  $selector: &;
  $currentSelector: "";
  @each $unit in $modifier {
    $currentSelector: #{$currentSelector + & + $modifier-separator + $unit + ","};
  }

  @at-root {
    #{$currentSelector} {
      @content;
    }
  }
}

5. 小结

我在这也就是抛砖引玉的说下，精彩的内容还是要大家自己去源码里看，或者自己去试着写一下那就是最好了。

试着写一个vue或者react的组件用上BEM范式去管理类名，肯定也会和我一样，觉得在基于组件化开发的前端项目中，BEM范式绝对是我们管理css的一把利器。

当然，在以后的文章中我也会来说说OO和SMA范式。

在我学习js的过程中，爱民老师的绿皮书里将js的类型系统分成了两类：

其一是元类型系统：由typeof运算来检测

其二是对象类型系统：是元类型的object的一个分支

而null这个关键字也被归类到了对象类型系统里面了：

• 是属于对象系统的
• 对象是空值

所以，当我们使用typeof去考察Null的话，会返回给我们”object”。

如果去用for(... in null)的方式试图去枚举Null里面的属性的时候。ES5会先行判断null和undefined，如果是这两个值的话，不会去执行循环体。

而我认为这一切都是null既无属性也无方法导致的。而且null也并无原型，也并不是Object()构造器或者其子类实例而来的。

而我是c#出身的前端，我觉得将null归类到对象系统里面是一个不错的选择！

2.《你不知道的js》里面怎么说的？

当我看到第三章的对象的时候，里面有这样一段话：

null 有时会被当作一种对象类型，但是这其实只是语言本身的一个 bug，即对 null 执行
typeof null 时会返回字符串 “object”。实际上，null 本身是基本类型

看到这里，完全颠覆我的认知啊！

按照”u dot know”里面的划分的话其实也是书里面很常见的一种划分方式。高程3中就是这样来划分js的类型系统的。但是，因为我觉得爱民老师这样的划分方式也没什么不妥。一切都是看待问题的角度不同导致的。而爱民老师将null归类到对象类型里面去，因为在js中除了undefined之外的都是对象。

而”u dot know”直接耳提面命的告诉我：你一直理解的js类型系统，是错的！

// 'u dot know'里的注解
// 原理是这样的，不同的对象在底层都表示为二进制，在 JavaScript 中二进制前三位都为 0 的话会被判
// 断为 object 类型，null 的二进制表示是全 0，自然前三位也是 0，所以执行 typeof 时会返回"object"。

3.到底怎么理解？

因为有了疑虑，所以我们要去探查真相！

终于，贺老给了我们一个很好的回答！

hax主要说了以下几个点：

• 爱民老师是按照自己的理解来分类的，而不是按照ECMA来照本宣科的，况且他写书的时候ES5/ES6还没有出来，而ES5之前的ES规范其实都写得比较烂
• 现在比较普遍的认知是，typeof null返回”object”是一个历史错误（JS的发明者Brendan Eich自己也是这样说的），只是因为要保持语言的兼容性而维持至今。从ES5制定开始就有动议将typeof null改为返回”null”（如启动node加上”–harmony_typeof”参数，即是如此），但是当前ES6标准草案仍然维持了原样。
• 按照爱民的意见，也可在某种程度上理解为null实为object类型的一个特殊值。在诸如Java这样的语言中，一个变量若是primitive类型，均不可赋以null值，而若是 object，则均可赋以null值。因为在理解上来说，null实际是引用（reference）的特殊值（表示没有指向任何实际对象）
• ECMA是如何划分概念，主要是依据ECMA的逻辑，而不是其他标准。所以从ECMA的逻辑看，类型系统是这样划分的，也是合理的

4.结论

古人常云：尽信书不如无书。书中的知识也是作者按照自己对语言了解的深度和他自己涉猎的广度的一个综合的体现。而我们看书，其实就是和作者交流的过程。

所以，你说爱民老师说的对吗？
对也不对！狭义的看，如果按照ECMA来说，就不对。但是，广义的看，如果你觉得按照爱民老师的划分，让你对js的类型系统保持了你对”对象”一贯的理解，那就是对的。

那你说，ECMA是对的吗？
对也不对！狭义的看，标准一般都是对的。但是，广义的看，如果你觉得把null不归为对象系统，不符合你对高级语言的认知，那也可以说是不对。

那么，回到我这篇文章的标题，js中的null，你觉得是对象吗？
我可能并不会去正面回答我提出的问题了，但是，我想说的是，至少我现在并不会对于”u dot know”里面说到的这个问题而耿耿于怀了！

从手写不同尺寸的媒体查询css到以手淘的flexible.js来进行移动端的适配，虽然过程曲折，不过效果也是十分的显著，因为有了成熟的体系以后，什么东西就有据可寻，适配也就没那么困难了。

但是，因为这次引入了高德地图，所以在适配上出现了一点意料之外的问题。

首先，我要说下视口这个东西，因为手淘的这个方案是严重依赖视口这个概念的。

1. 视口

1.1 视口的分类

ppk将视口分为三大类：布局视口、可视视口、理想视口。

那视口是什么呢？通俗点说就是浏览器上（也可能是一个app中的webview）用来显示网页的那部分区域，但viewport又不局限于浏览器可视区域的大小，它可能比浏览器的可视区域要大，因为为了正常的显示PC端的网页，浏览器会将自己的layout viewport设置为一个较大的值，结果就是会出现左右的滚动条。

布局视口和可视视口我们作基本了解即可。在实际工作中，我们需要接触和处理的更多是ideal viewport。

而我们前端一直孜孜以求的移动端的适配，其实就是为了让用户的浏览器中呈现的是我们的理想视口。

ideal viewport并没有一个固定的尺寸，不同的设备拥有不同的ideal viewport。早期移动端开发，对于终端设备适配问题只属于Android系列，有320pt的，有360pt的，有384pt的等等。但随着iPhone6、iPhone6+的出现，从此终端适配问题不再是Android系列了，也从这个时候让移动端适配全面进入到”杂屏”时代。

http://viewportsizes.com 里面收集了众多设备的理想宽度。

1.2 如何影响视口？

既然viewport这么重要，那我们怎么去控制他为我所用呢？这个时候，就轮到meta标签出场了。

<meta
  name="viewport"
  content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0"
/>

content里面的属性说明：

<!-- 将 layout viewport => ideal viewport -->
<meta name="viewport" content="width=device-width" />
<meta name="viewport" content="initial-scale=1.0" />

上面两种方式是殊途同归的。那么，为什么我们还要将两个都写上去呢？

• initial-scale=1.0：处理在 iPhone、iPad 上，无论竖屏还是横屏，宽度都是竖屏时 ideal viewport 宽度的问题。
• width=device-width：处理在 Windows Phone 上的 IE 无论竖屏还是横屏都把宽度设为竖屏时 ideal viewport 宽度的问题。

<meta name="viewport" content="width=400, initial-scale=1.0" />

如果出现了上面这种冲突，浏览器会取两者中较大的那个值。总结起来就是”谁大谁先行”。

2. 引入高德后页面的表现

在vue的spa项目中引入高德以后，我们发现在不同的dpr下，地图的显示效果差距非常大。

在dpr=3的时候，也就是plus的机型上，地图显得格外的小，几乎用肉眼是无法看清上面的字体。所以，基于flexible的适配方法肯定是有问题的了。

而出现这个问题的原因就是我们的viewport被缩放了。

if (!dpr && !scale) {
  var isAndroid = win.navigator.appVersion.match(/android/gi);
  var isIPhone = win.navigator.appVersion.match(/iphone/gi);
  var devicePixelRatio = win.devicePixelRatio;
  if (isIPhone) {
    // iOS下，对于2和3的屏，用2倍的方案，其余的用1倍方案
    if (devicePixelRatio >= 3 && (!dpr || dpr >= 3)) {
      dpr = 3;
    } else if (devicePixelRatio >= 2 && (!dpr || dpr >= 2)) {
      dpr = 2;
    } else {
      dpr = 1;
    }
  } else {
    // 其他设备下，仍旧使用1倍的方案
    dpr = 1;
  }
  scale = 1 / dpr;
}

通过上面的代码计算出了viewport缩放的比率。当处于iPhone 6+ Plus的时候，scale = 0.3333...

metaEl.setAttribute(
  "content",
  "initial-scale=" +
    scale +
    ", maximum-scale=" +
    scale +
    ", minimum-scale=" +
    scale +
    ", user-scalable=no",
);

最后写到页面上面的结果就是：

<meta
  name="viewport"
  content="initial-scale=0.3333333333333333, maximum-scale=0.3333333333333333, minimum-scale=0.3333333333333333, user-scalable=no"
/>

所以，iPhone Plus是414pt，通过flexible将viewport缩小了0.333…，414 / 0.333... = 1242，而正好高德地图通过canvas绘制的画布宽度也就是1242。

3. 如何解决这个问题

处理这个问题的方法大致有三种。

3.1 通过vue-router的路由守卫进行处理

beforeMount() {
  this.$nextTick(() => {
    const dpr = document.documentElement.getAttribute('data-dpr')
    if (dpr > 1) {
      window.tempViewport = document.querySelector('meta[name="viewport"]').getAttribute('content');
      document.querySelector('meta[name="viewport"]').setAttribute('content', 'width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no');
      window.tempDpr = dpr;
      document.documentElement.setAttribute('data-dpr', 1);
    }
  })
},
beforeRouteLeave(to, from, next) {
  if (window.tempViewport) {
    document.querySelector('meta[name="viewport"]').setAttribute('content', window.tempViewport);
    delete window.tempViewport;
  }
  if (window.tempDpr) {
    document.documentElement.setAttribute('data-dpr', window.tempDpr);
    delete window.tempDpr;
  }
  next()
},

不过这样的方式不是很好，因为页面在过渡的时候会出现一瞬间样式的变形。而且如果在当前有地图的页面有其他结构的话，其他结构也会错乱。

Tips：如果不是SPA的应用，而且整屏页面是地图占满的情况下，这个方案还是可行的。

3.2 通过css scale属性

这个方法在试验了以后，也存在问题。虽然地图的大小是正常了，但是在地图上进行点标记的时候，会出现地图位置的偏移。

Tips：如果仅仅是展示，而并没有任何交互的情况下，这个方式也是可行的。

3.3 通过设置dpr=1（推荐）

通过设置dpr=1，强制flexible布局对viewport不进行缩放。

<meta name="flexible" content="initial-dpr=1" />

这样，最后写到页面上的meta标签就是：

<meta
  name="viewport"
  content="initial-scale=1,maximum-scale=1,minimum-scale=1,user-scalable=no"
/>

既然viewport没有缩放了，高德地图通过canvas绘制的地图也就是按照我们的ideal viewport来进行处理了。

不过这种方式会产生另外两个副作用：

• 通过缩放来处理的”1px问题”需要重新去处理
• 通过dpr设置的不同dpr下的文本字号大小，可能会出现13px这样很奇葩的尺寸

4. 结尾

大漠对于这个问题的解释是：flexible已经完成自己的使命，该功成身退了。他推荐使用vw、vh标准的新布局方式。

而到底用不用这套方案，作为前端的我们也是见仁见智了！

并且，配合axios这样的第三方库，我们可以实现配合后台接口的拦截器功能。

对于一个小型项目而言，router这个文件夹里面就包含了一个router.js就足够了，但是，当我们的页面比较多的时候，我们就需要分出两个文件出来：一个定义我们的路由和组件，另一个实例化组件，并将路由挂载到vue的实例上。

基本的用法就不多赘述，大家可以看 vue-router 的官网，认真过一遍的话，基本使用肯定没什么问题。

1. 为什么我的路由不起作用？

这里有个非常重要的一点就是当我们去构造VueRouter的实例的时候，传入的参数的问题。

import routes from "@/router/router";

const router = new VueRouter({
  routes, // （ES6语法）相当于 routes: routes
});

new Vue({
  router,
}).$mount("#app");

如果你这里引入的不是routes，你就要按照下面的方式来写：

import vRoutes from "@/router/router";

const router = new VueRouter({
  routes: vRoutes,
});

new Vue({
  router,
}).$mount("#app");

2. 在路由中基于webpack实现组件的懒加载

对于我们的vue项目，我们基本都是运用webpack打包的，如果没有懒加载，打包后的文件将会异常的大，造成首页白屏，延时严重，不利于用户体验。而运用懒加载则可以将页面进行划分，webpack将不同组件打包成很多个小的js文件，需要的时候再异步加载，优化用户的体验。

import App from "@/App.vue";

const index = (r) =>
  require.ensure([], () => r(require("@/pages/index/index")), "index");

export default [
  {
    path: "/",
    component: App,
    children: [
      {
        path: "/index",
        name: "index",
        component: index,
      },
    ],
  },
];

如果某个组件包含了嵌套路由，我们也可以将两个路由打包到一个js chunk中：

// 这两条路由被打包在相同的块中，访问任一路由都会延迟加载该路由组件
const orderUser = (r) =>
  require.ensure([], () => r(require("@/pages/order/user")), "order");
const payRecord = (r) =>
  require.ensure([], () => r(require("@/pages/order/payRecord")), "order");

3. router的模式

对于浏览器，我们的router分为两种模式。

1. hash模式（默认）

按照一个uri的基本结构来说，hash模式就是在一个基本的URI的片段进行的处理。如果抛开SPA的话，比较常见的应用场景就是我们在做pc商城的时候，会有比如说：商品详情、评论、商品参数这样的tab切换，就可以使用a标签配合id使用，加上一点运动的特效，效果甚佳。

这也是router默认使用的路由方式。不过，这种方式有一个弊端，就是在接入第三方支付的时候，我们传入一个url给到第三方支付作为回调地址，但是在支付完成以后，有的第三方支付会把我们的#作为一个截取符号，仅保留第一个#符号前面的url内容，后面再添加相应的回调参数，导致支付完成以后无法跳转到相应的支付页面。

传入的url:
http://xx.xx.com/#/pay/123

回调后的地址:
http://xx.xx.com/pay/123?data=xxxxx%xxxx

2. history模式

还有一种就是history的模式。它是使用h5的history.pushState来完成URL的跳转的。使用这种方式来处理跳转的好处就是，url和我们平常看到的没有什么区别，和hash模式作比较的话就是没有了#。不过使用history模式，我们在后台也要去做相应的处理，因为如果直接去访问一个地址，例如http://www.xxxx.com/user/id的时候，如果后端没有配置，后端就会返回404页面。

4. router-link在循环中this.参数名=undefined

<router-link> 组件是我们在view层中需要用到的跳转组件。它替代了<a>标签需要做的事情，并且帮助我们做了更多的事情：

• 无论是 h5 history 模式还是 hash 模式，它的表现行为一致，所以，当你要切换路由模式，或者在 IE9 降级使用 hash 模式，无须任何变动。
• 在 HTML5 history 模式下，router-link 会守卫点击事件，让浏览器不再重新加载页面。
• 当你在 HTML5 history 模式下使用 base 选项之后，所有的 to 属性都不需要写（基路径）了。

不过当我们在v-for的循环中使用了router-link的时候，如果需要取一个我们在data中定义的值，我们是通过this.foo来取呢？还是通过foo来取呢？

这里的话，我们是不能通过this.foo来取的，因为这里的this不再是指向vue的实例了，而是指向了[object Window]。所以用this.foo来取的话，其实是undefined。

<router-link
  tag="li"
  :to="{path:`/user/${item.userID}`}"
  v-for="(item, index) in userList"
  :key="index"
>
  <!-- this.foo 是 undefined，应直接用 foo -->
  <p>{{this.foo}}</p>
  <p>{{foo}}</p>
</router-link>

data(){
  return {
    foo: 'bar',
  }
}

5. vue-router配合axios的使用

初次接触拦截器这个概念是在java中，通过拦截器，我们可以对用户的登录状态进行更加粒度的操作。而对于一个SPA的应用来说，没有了后台路由的介入，我们就需要在前端实现一套自己的登录状态的管理机制。

最直观的一点就是，通过用户的token来判断用户是否登录：

router.beforeEach((to, from, next) => {
  const NOW = new Date().getTime();
  if (to.matched.some((r) => r.meta.requireAuth)) {
    if (NOW > store.state.deadLine) {
      store.commit("CLEAR_USERTOKEN");
    }
    if (store.state.message.login === true) {
      next();
    } else {
      next({
        path: "/login",
        query: { redirect: to.fullPath },
      });
    }
  } else {
    next();
  }
});

上面的代码中，我们通过vue-router中的全局守卫，在导航触发的时候大致做了如下几件事：

1. 判断导航的页面是否需要登录
2. 超过登录持久期限，清除持久化的登录用户token
3. 没有超过登录期限，判断是否登录状态
4. 没登录，重定向到登录页面

但是，仅仅这样是不够的。因为用户直接不正常注销而直接后台运行网页是很正常的事情，这就导致虽然token是存在的，但是对于后台而言，这个token是无效的、过期的了。所以，我们需要axios配合后台给出的状态码来完善我们的拦截器。

import router from "@/router/routes";

axios.interceptors.response.use(
  (success) => {
    switch (success.code) {
      case -100:
        router.replace({
          path: "login",
          query: { redirect: router.currentRoute.fullPath },
        });
        console.warn("注意,登录已过期!");
        break;
    }
    return success;
  },
  (error) => {
    switch (error.code) {
      case 404:
        console.warn("请求地址有误或者参数错误!");
        break;
    }
    return Promise.reject(error.response.data);
  },
);

通过后端给到的登录过期状态码（这里以-100为例），我们可以用axios的响应拦截器实现，当我们的token过期的时候，将页面重定向到登录页面去。

6. 巧用replace替换push

在项目中，有的同事就是一直this.$router.push(...)，从开始push到结尾。

碰到有的页面，比如说，在选择地址的时候需要知道用户当前所在的城市，如果没有的话，就重定向到城市列表页面去手动选取。选择完成以后再回到选择地址的页面，如果一直使用push的话，点击选择地址的后退时，就会回退到城市列表页，造成页面间的死循环。

这里如果使用replace来操作就没有什么问题了，问题就是我们不应该让城市列表页出现在我们的浏览历史里面。

一个vue的项目，我觉得最小的子集其实就是{vue,vue-router,component}，vue作为基础库，为我们提供双向绑定等功能。vue-router连接不同的”页面”，component作为样式或者行为输出，你可以通过这三个东西来实现最基本的静态SPA网站。当然我在这里不谈vue全家桶这样宽泛的概念，我会如数家珍的把主要的技术点一一列举。

1. vue-cli：搭建基本的vue项目骨架，脚手架工具
2. sass-loader&node-sass：使用sass作为样式的预编译工具，两者缺一不可
3. postcss：实现响应式布局的关键，px=>rem
4. vuex：管理复杂的数据流向，状态机工具，特化的Flux
5. vuex-persistedstate：将vuex中state持久化的工具
6. vue-router：实现SPA间”页面”之间的跳转
7. vue-lazyload：实现图片的懒加载，优化http传输性能
8. vue-awesome-swiper：轮播功能的实现及一些特殊切换效果的完成
9. better-scroll：实现列表滚动及父子组件间的滚动问题
10. axios：http工具，实现向API请求数据，以及拦截器的实现
11. fastclick：解决300ms延迟的库

以上这些，都是我觉得一个中大型的vue项目需要用到的，还有一些比如我在实现图片上传中用到了jsx的语法，需要babel-jsx这样的东西，不具有普适性，就不例举了。

下面简述一下上面说到的这些东西，有的东西会单独的来出来细说：

1. vue-cli

https://github.com/vuejs/vue-cli

脚手架工具，当我们选择vue作为我们的开发技术栈以后，就要开始为我们的项目搭建目录及开发的环境。安装好node以后，通过以下命令进行安装：

npm install -g vue-cli          # 将vue-cli安装到全局环境
vue init webpack my-vue-demo    # 创建基于webpack模板的vue项目

这里的模板有6种，不过我们比较常用的就是webpack了。

期间你会看到有一些例如e2e这样的单元测试的工具和ESLint检测代码质量的工具，我觉得都是可以不必安装的。

那么，其实我们最关心的就是在src文件夹下面的内容了。可以看下图：

上图就是一个在刨除vue-cli的基本结构，在项目上比较成熟的vue骨架了。

2&3. sass, postcss

直接写css的洪荒时代已经过去了，预编译的样式处理器帮助我们解放了生产力，提高了效率。sass、less、stylus各有优缺，也各有信徒。

要使用sass的话，你需要安装sass-loader和node-sass，不过node-sass不是很好装，被墙的厉害，建议还是用taobao的镜像。如果安装完成后还是报错无法解析的话，你可能就需要去webpack.base.conf.js里去看看是否设置好了对应的loader。

postcss的常用功能：

• px2rem：可以帮助我们实现px到rem单位的转换，只需要你定义好相应的转换标准就可以了。
• autoprefixer：兼容性的处理postcss也可以帮我们处理好。

// vue-loader.conf.js
module.exports = {
  loaders: utils.cssLoaders({
    sourceMap: isProduction
      ? config.build.productionSourceMap
      : config.dev.cssSourceMap,
    extract: isProduction,
  }),
  postcss: [
    require("autoprefixer")({
      browsers: ["iOS >= 7", "Android >= 4.1"],
    }),
    require("postcss-px2rem")({ remUnit: 64 }),
  ],
};

4, 5. vuex, vuex-persistedstate

https://github.com/robinvdvleuten/vuex-persistedstate

一个中大型的vue项目，肯定有复杂的状态需要去管理。简单的event bus已经不再适用了。

特化的Flux架构，vuex就迎头顶上。简而言之：他就是我们处理无论是用户操作、API返回、URL变更等多重操作的状态管理工具。

用过vuex的人，会发现一个很痛苦的地方，就是vuex里面的state，只要我们去刷新，它就被释放掉了。vuex-persistedstate帮我们解决了这样的问题，它帮我们直接把state映射到了本地的缓存环境，我们可以在computed里面用vuex提供的mapState辅助函数，来动态的更新local里面的数据。而不需要持久化的state，我们依旧可以刷新来释放掉。

6. vue-router

当我们使用vue来构建SPA的应用时，就等于说我们完全的分离了前后端。后端仅仅提供数据，任何的逻辑都在前端实现。vue-router就帮我们做了这样的事情，他提供给了路由守卫给我们，我们可以设置全局的、组件内的路由守卫，来实现特定的业务逻辑，提供过渡动画等等。

7. vue-lazyload

https://github.com/hilongjw/vue-lazyload

实现图片的懒加载。这是前端性能优化的一个必须面对的问题：图片。懒加载可以减少请求的数量，而且在很直观的视觉上，也有一个良好的过渡。当然，图片我们也是需要去做一些处理的，使用webp格式来减小图片的质量，或者通过oss来对图片作处理。

8. vue-awesome-swiper

https://github.com/surmon-china/vue-awesome-swiper

通过它可以实现基本轮播、横轴的切换、横轴的列表滚动等。

例如我要去实现四个tab切换这样的功能，但是简单的display这样的效果我又觉得不是很满意。那么我们就可以通过swiper来实现，每次tab里面的content都会对应swiper的一个swiper-item。切换的tab，其实就是swiper里面的next page或者before page。

data(){
  return{
    swiperOption: {
      slidesPerView: 'auto',
      direction: 'horizontal',
      freeMode: true,
      loop: false,
      spaceBetween: 20,
    },
  }
}

<swiper :options="swiperOption" ref="swiper" v-if="list && list.length !== 0">
  <swiper-slide v-for="(item,index) in list" :key="index" class="hot-item">
    <router-link
      :to="{name:'quickCar',params:{carID:item.CarID}}"
      class="description_car"
    >
      <img
        v-lazy="item.Attachments.length !==0 && item.Attachments[0].FilePath"
      />
      <span>&yen;{{item.price}}/日</span>
    </router-link>
  </swiper-slide>
</swiper>
<p class="noData" v-else></p>

9. better-scroll

https://github.com/ustbhuangyi/better-scroll

实现纵轴列表的滚动，以及当有嵌套的路由的时候，通过better-scroll来实现禁止父路由随着子路由滚动的问题。

better-scroll其实也可以去实现横轴的滚动，但是为什么不使用better-scroll来处理呢？这是因为在better-scroll实现横轴滚动的时候，我们无法在better-scroll的content的内容区域里去向下拉动我们的页面。所以导致的一个Bug就是，在better-scroll横轴滚动的区域里，页面动不了了。

如上图：横轴滚动下面还有内容，但是在图片所示的区域里面，无法向下拉动。所以横轴的滚动其实也是通过vue-awesome-swiper来实现的。

10. axios

基本功能就是通过axios来请求后台接口的数据。并且axios可以配合router更好的实现类似后台的拦截器的功能，例如处理token过期这样的问题。因为当token过期的时候，仅仅通过vue-router的router.beforeEach来处理就有点无能为力了。这时候就需要配合后台响应返回的code来进行url的处理。

11. fastclick

解决点透和点击延时的问题。

具体可以看钗神的源码分析：https://www.cnblogs.com/yexiaochai/p/3442220.html