传统的 LIKE 模糊查询（前置百分号）无法利用索引，特别是多个关键词 OR，或在多个字段中 LIKE，更是效率低下。本文研究对文章进行分词以提高检索的准确度和查询效率。
根据自己的编程语言选择一款合适的中文分词组件，我在 ASP.NET 平台下选择了 jieba.NET。
设想的步骤：
分别对文章标题、标签、正文进行分词，保存到一张分词表上。该表把“文章 ID”和“词语”设为联合主键，用 3 个字段记录该词语分别在标题、标签、正文中出现的次数，另外还可以按需要添加文章分类 ID、文章创建时间等字段。
当用户输入关键词进行检索时，先将关键词分词，在分词表中用 in 语法查询到所有相关的记录；
使用 group by 语法对查询结果按文章 ID 分组；
关键在排序上，理想的排序是：
a. 先按搜索关键词中不同词语的出现量排序，即：若搜索关键词分词后是 3 个词语，那么全部包含这 3 个词的文章优先，只匹配其中 2 个词语的其次；
b. 再按搜索关键词在文中累计出现的次数排序（考虑权重），即：我们先假定标题和标签的分词权重为 5（意思是一个分词在标题中出现 1 次相当于在正文中出现 5 次），那么累加每个分词在标题、标签、正文的权重次数，得分高的优先；
c. 再进一步考虑文章的发布时间，即将文章的发布时间距离最早一篇文章的发布时间（或一个较早的固定日期）相隔的天数，乘以一个系数加入到权重中，这个系数按不同文章分类（场景）不同，比如新闻类的大一点，情感类的小一点）。乘以系数时一篇文章只加权一次，不要加权到每个分词。
d. 根据需求还可以加入文章热度（阅读数）的权重。
根据上述逻辑对一个有 18 万篇文章的内容管理系统进行改造，循环所有文章进行分词统计，得到一张包含 5 千万条记录的分词表（系统中部分文章只有标题、标签和外链，没有正文，否则更多）。
由于查询中包含 in、group by、count、sum、运算等，再若分类是无级限的，即文章分类 ID 也是 in 查询，然后分页，即使创建索引，效率也只能呵呵了。
简化：
不对正文进行分词；
不按权重进行排序；
那么分词表的记录数降到 250 万条，同样用 in 查询分词，先按搜索关键词中不同词语的出现量排序，再按发布时间排序，分页后获得一页的文章 ID 集合，再去文章表中 in 获取详细信息（注意保持一页中的排序）。
添加相关索引后，查询一个包含 3 个分词的关键词仅需十几毫秒。因为 in 的内容比较离散，所以索引的利用率比较高。
当微信支付的 notify_url 填写的是 https 的回调地址时，如果遇到支付成功但没有接收到回调的情况，可能是服务器开启了 SNI。
SNI，即服务器名称指示，用于在一台服务器上支持多个网站使用不同的 SSL 证书。
解决方案：
方法一、
notify_url改为 http 的回调地址，缺点是容易被运营商 QJ，而且如果日后网站开启强制要求 https 访问就会使回调失败；方法二、【不推荐】可以为该网站单独配置一台服务，不使用 SNI，缺点是增加成本；
方法三、【推荐】该网站仍然“需要服务器名称指示”，在 IIS 中给默认网站（不是当前网站）添加一个 https 的域名绑定，不勾选“需要服务器名称指示”，证书随便选一个。缺点是时间一长容易忘记有这回事，不要轻易删除该绑定就好了，而且在网站搬迁的时候也同样要做该配置。
感谢 V2EX
本文讲述使用网页开发适用于宴会、活动、年会现场 LED 大屏幕显示抽奖、抢楼、游戏、视频等互动界面，通过在浏览器中打开后 F11 全屏投影到大银幕上。
设计思路：
为了保证最佳的显示效果，设计稿的尺寸按大屏幕的“宽高比”来做（本文以4米*3米的大银幕为例，设计稿以800*600像素为例）。
由于电脑的视频输出分辨率很有可能与大银幕的宽高比不同，那么我们全屏投影后会界面会有变形，但是投影设备接收到电脑视频信号后再全屏显示到大银幕时，界面又会变回正常。
按设计稿的尺寸开发网页，并使用 CSS3 的 scale 实现整体伸缩，目的是自适应窗口尺寸来全屏显示内容，无留白、无裁切。整体拉伸的要求是文字、图片、背景、间距、iframe 等所有元素以统一的比例拉伸，无错位。
网页上通过 JS 设置一些快捷键来实现页面展示内容的切换。
若投影设备功能有限或操作员水平有限等原因导致无法顺利设置输入输出分辨率时，网页可设置 x 轴和 y 轴两个方向的伸缩系数、定位偏移量等，更灵活地实现完美投影需求。
开发要点：
网页尺寸按设计稿来定（以 800x600 为例）。
使用 CSS3 的 transform 的 scale 来实现缩放，以电脑显示器分辨率 1920x1080，宽放大 1920/800 倍，高放大 1080/600 倍，即可将设计稿全屏展示到电脑显示器上。为了更灵活，我们使用窗口大小来代替显示器分辨率，这样不管怎么改变窗口大小或者全屏，设计稿都能完整地显示在窗口上。
在页面初始化和窗口尺寸变化时重新调整设置上述比例。
代码参考：
这是一篇可能解决困扰了 .NET 程序猿多年的文章！
首先，使用 Visual Studio 2019 创建一个 ASP.NET WEB 应用程序，直接选用了 MVC 模板。
直接发布项目，默认的设置如下图：
对于小型项目，按默认设置发布基本可满足正常运行，首次运行打开第一个页面基本在 5~6 秒（视服务器配置），其它页面的首次打开也基本在 1~2 秒完成，非首次瞬间打开。
一旦项目功能变得复杂，文件增多，会导致发布后首次运行打开第一个页面 30 秒以上，其它页面的首次打开 10 秒左右，非首次瞬间打开。
这是因为项目在发布时没有进行预编译，而是在用户访问网页时动态编译，一旦应用程序池回收，或项目文件改动，都会重新编译，再次经历缓慢的“第一次”，这是不能忍的。
于是咱们来研究一下“预编译”。
在发布页面勾选“在发布期间预编译”，这时发布会在“输出”窗口显示正在执行编译命令（编译时间会比较长）：
该选项对发布后的文件结构和内容影响不大，因此对首次执行效率的提升也不大，重要的在后面。
在“高级预编译设置”窗口中：
我们针对预编译选项和合并选项分别做测试。
不勾选“允许更新预编译站点”，会致 bin 目录中生成许多 .compiled 文件，而所有 .cshtml 文件的内容都是：
这是预编译工具生成的标记文件，不应删除!
如果是 Web From 网站，.aspx/.ashx 等文件内容同上。
尝试打开网站页面，你会发现，除了项目启动后的第一个页面仍然需要 1~2 秒（无 EF），其余每个页面的首次都是瞬间打开的（EF 的首次慢不在本文讨论范围）。这让我对预编译有一种相见恨晚的感觉！
这里偷偷地告诉你，把 Views 目录删掉也不影响网页正常打开哦~为什么不让删，咱也不敢问，咱也不敢删。
目的达到了，有一些后遗症需要解决，比如 bin 目录内杂乱无章。
选“不合并。为每个页面和控件创建单独的程序集”，结果是 bin 多出许多 App_Web_*.dll 文件。
选“将所有输出合并到单个程序集”，填写程序集名称。这时会发现“输出”窗口执行了命令：
如果程序集名称跟已有名称冲突，会发生错误：
合并程序集时出错: ILMerge.Merge: The target assembly '******' lists itself as an external reference.
查看 bin 目录，.compiled 文件还在，但 App_Web_*.dll 合并成了一个程序集。FTP 的“不合并”也是把所有 App_Web_*.dll 上传一遍，所以不存在相对于“合并”的增量发布优势。
是不是勾了“视为库组件删除(AppCode.compiled 文件)”.compiled 文件就会不见？意外之外，情理之中，bin 没有什么变化。
继续选择“将各个文件夹输出合并到其自己的程序集”，呃，bin 中文件数不降反增。
最后选择“将所有页和控件输出合并到单个程序集”，同样程序集名称不能冲突。结局令人失望，bin 中仍然一大堆 .compiled 和 App_Web_*.dll。
整理成表格：
| 1 | 允许更新预编译站点 aspnet_compiler.exe -v / -p \Source -u \TempBuildDir 重复发布后 bin 目录文件数：不会增多（页面不进行预编译） |
| 2 | 不允许更新预编译站点，不合并 aspnet_compiler.exe -v / -p \Source \TempBuildDir 重复发布后 bin 目录文件数：.compiled 不会增多，App_Web_*.dll 增多 |
| 3 | 不允许更新预编译站点，不合并。为每个页面和控件创建单独的程序集 aspnet_compiler.exe -v / -p \Source -c -fixednames \TempBuildDir 重复发布后 bin 目录文件数：不会增多（编译后的文件名固定，FTP 方式的部分 App_Web_*.dll 文件可能实现增量上传） |
| 4 | 不允许更新预编译站点，将所有输出合并到单个程序集，不勾选“视为库组件” aspnet_compiler.exe -v / -p \Source -c \TempBuildDir aspnet_merge.exe \TempBuildDir -o 程序集名称 -copyattrs AssemblyInfo.dll -a 重复发布后 bin 目录文件数：不会增多（.compiled 固定名称，App_Web_*.dll 合并为一个） |
| 5 | 不允许更新预编译站点，将所有输出合并到单个程序集，勾选“视为库组件” aspnet_compiler.exe -v / -p \Source \TempBuildDir aspnet_merge.exe \TempBuildDir -o 程序集名称 -copyattrs AssemblyInfo.dll -a -r 重复发布后 bin 目录文件数：不会增多（.compiled 固定名称，App_Web_*.dll 合并为一个） |
| 6 | 不允许更新预编译站点，将每个文件夹输出合并到其自己的程序集，前缀 aspnet_compiler.exe -v / -p \Source -c \TempBuildDir aspnet_merge.exe \TempBuildDir -prefix 前缀 -copyattrs AssemblyInfo.dll -a 重复发布后 bin 目录文件数：.compiled 不会增多，App_Web_*.dll 增多 |
| 7 | 不允许更新预编译站点，将所有页和控件输出合并到单个程序集 aspnet_compiler.exe -v / -p \Source -c \TempBuildDir aspnet_merge.exe \TempBuildDir -w 程序集名称 -copyattrs AssemblyInfo.dll -a 重复发布后 bin 目录文件数：.compiled 不会增多，App_Web_*.dll 增多 |
bin 目录下，页面的程序集文件（App_Web_*.dll）增多的原因是编译后的文件名不固定，发布到会导致残留许多无用的程序集文件。
相比较，如果第 3 种能实现 FTP 稳定的增量上传的话是比较完美的（还有一个缺点是：如果页面有删除，目标 bin 内对应该页面的 .compiled 和 .dll 不会删除，这跟“允许更新预编译站点”是一个情况），那么第 4 种 或第 5 种也是不错的选择（同样有缺点：执行合并比较慢）。
测试一个有 300 个页面的项目，compiler 用时约 2 分钟，merge 用时约 5 分钟，发布用时约 4 分钟。
这里有个槽点，执行预编译和合并是佛系的，CPU 和磁盘使用率永远保持在最低水平。
所以如果是要经常修改的项目，那么建议选择“不合并”的第 3 种发布方式：
“视为库组件（删除 AppCode.compiled 文件）”：移除主代码程序集（App_Code 文件夹中的代码）的 .compiled 文件。 如果应用程序包含对主代码程序集的显式类型引用，则不要使用此选项。
补充：
不允许更新预编译站点发布后，因为前端页面没有内容，因此无法单独修改发布（单独发布一个页面后，在访问时不会生效！），只能全站发布，耗时较长；bin 目录有变动将导致使用 InProc 方式存储的 Session 丢失。
预编译的另一个优点是可以检查 .aspx / .cshtml 页面 C# 部分的错误（特别是命名空间和路径引用）。
改为预编译发布后，可以将服务器上残留的 .master / .ascx / .asax 删除，但不能删除 .aspx / .ashx /.config 等。
VS 发布到 FTP 经常会遗漏一些页面文件，不合并时会遗漏独立文件，合并后也会遗漏合并后的 .dll 的文件，合并的好处就是方便检查是否完全上传发布。
慎选“在发布前删除所有现有文件”！一旦勾选发布，世界就清静了，所有网友上传的图片附件以及网站运行产生的其它文件，消失得无影无踪。不管发布到文件系统还是发布到 FTP 都一样。当然，如果是先发布到文件系统，再通过 FileZilla 等 FTP 软件上传到服务器的，建议勾选此项。
.NET Core 应用程序部署：https://docs.microsoft.com/zh-cn/dotnet/core/deploying/index
由于上传文件时 bin 目录文件较多，理论上 bin 目录内的文件有任何改动都会重启应用池，而且 VS 是单线程上传的，导致期间网站访问缓慢，服务器 CPU 升高，我的做法是：发布到文件系统，再使用专用 FTP 工具上传，上传用时约半分钟（如果大小不同或源文件较新则覆盖文件）。还嫌慢？那就打包上传，解压覆盖。
关于本文研究对象的官方解释：高级预编译设置对话框
出现“未能加载文件或程序集“***”或它的某一个依赖项。试图加载格式不正确的程序。”的问题时，先用改用 Debug 方式发布会报详细错误，一般是 .aspx 等客户端页面有 C# 语法问题，注意提示报错的是 /obj/ 目录下的克隆文件，应更改原文件。排除错误后关闭所有页面，再使用 Release 方式发布。
如果你是刚入手的小米 WiFi 电力猫，那么按说明书一步一步配置即可。这里记录一下移机的重置方法。
本次移机的场景是电力猫从一台小米路由器更换到另一台小米路由器的配置，两台小米路由器 WIFI 的 SSD 不同（假设为 WIFI-A 和 WIFI-B）。
错误做法：打开米家，切换到 WIFI-B 所在的房间，点击右上角的添加新设备，根据介绍插上子猫，并按子猫的配置键 5 秒以上。连上“xiaomi-plc-xxx”，米家显示正在连接，但到达 100% 后显示连接超时。
可能的错误原因：
没有插上主猫
该电子猫已经在米家上添加过了（在 WIFI-A 所在的房间），就无法添加到其它房间了（仅猜测，未实测）
于是，同时插上主猫和子猫，并且路由器和主猫使用网线连接，什么都不设置，过一两分钟，两猫自动会变成蓝灯（表示连接成功）。这时，如果刚才那步没有重置成功的话，打开米家主界面上的“小米电力线wifi扩展器”（如果没有删除过，还在 A 房间），里面会显示网络名称为 WIFI-A，还可能没有开“WIFI漫游”。这样虽然能连接上网，但有两个 SSD，不能实现漫游。
这时，按子猫配置键 5 秒以上，并静等一分钟以上，变回蓝灯后，再打开米家，就会看到网络名称可能是 WIFI-B-Plus，这时"WIFI漫游”也能打开了，完美扩展了 WIFI。
综上实践得出：
WIFI 是由子猫负责的，所以跟 SSD 有关的配置由子猫负责；
一台设备（这里指电子猫套餐）只能添加到米家一次，但可以更改设备所在的房间。
正确的重置电力猫步骤是：
同时插上主猫和子猫
主猫连上路由器
子猫按配置键 5 秒以上，等待一分钟以上
打开米家，进入“小米电力线wifi扩展器”，打开 WIFI 漫游
以上仅在使用小米路由器情况下实测，非小米路由器未尝试。
使用以下代码对字符串 s 进行判断：
var s = null;
if (s) {
console.log('true');
} else {
console.log('false');
}测试当 s 为不同值时的结果如下：
| s 的值 | if(s) 的结果 |
| s = null; | false |
| s = undefined; | false |
| s = ''; | false |
| s = ""; | false |
| s = 0; | false |
| s = 1; | true |
| s = 2; | true |
| s = -1; | true |
| s = '0'; | true |
| s= ' '; | true |
结论：
当 s 未定义或未赋值时，结果为 false；
当 s 为字符串类型时，长度为 0 即 false，长度大于 0 即 true；
当 s 为数字类型时，等于 0 为 false，不等于 0 为 true。
如果判断 s 的长度：
var s = null;
if (s.length > 0) {
console.log('true');
} else {
console.log('false');
}那么会有以下结果：
| s 的值 | if(s.length > 0) 的结果 |
| s = null; | Uncaught TypeError |
| s = undefined; | Uncaught TypeError |
| s = ''; | false |
| s = ""; | false |
| s = 0; | false |
| s = 1; | false |
| s = 2; | false |
| s = -1; | false |
| s = '0'; | true |
| s= ' '; | true |
结论：
当 s 未定义或未赋值时，异常；
当 s 为字符串类型时，长度为 0 即 false，长度大于 0 即 true；
当 s 为数字类型时，永远为 false。
这样的话，if(s.length > 0) 等同于 if(s.length)。
综上所述，判断一个字符串是否“有值且长度大于 0 ”，可以这样写：
var s = null;
if (s && s.length) {
console.log('true');
} else {
console.log('false');
}相反，是否“无值或长度为 0”，可以这样写：
var s = null;
if (!s || !s.length) {
console.log('true');
} else {
console.log('false');
}当然，如果要将不为 0 的数字类型也视为“有值”，只要 if(s) 或 if(!s) 即可。
这是一个数据可视化项目，基于D3.js。能够将历史数据排名转化为动态柱状图图表。
先来看看效果：
https://xoyozo.net/Demo/BarGraph
作者 Jannchie 见齐还提供了官方视频教程：
https://www.bilibili.com/video/av28087807
不过由于开源项目的不断更新，该教程的部分内容已失效，本文针对 2018-12-25 版本总结了一些常用的配置说明，仅供参考。
从 GitHub 下载源代码，在 src 目录中可以看到 4 个文件：
bargraph.html --> 运行示例页面
config.js --> 配置文件
stylesheet.css --> 样式表
visual.js --> 核心文件
作者并没有将代码封装为插件的方式，所以我们是通过修改 config.js 配置文件的方式应用到自己的项目中的。
visual.js 虽然是核心文件，但作者将部分示例中的代码也包含其中，但并不影响我们直接在自己的项目中引用。
以下是 config.js 中的主要属性：
| 属性 | 说明 | 参考值 |
| encoding | 数据源（csv、json）等的文件编码 | GBK / UTF-8 等 |
| max_number | 每个时间节点最多显示的条目数 | 10 |
| showMessage | 控制是否显示顶部附加信息文字 | true / false |
| auto_sort | 时间自动排序（详细含义、作用及限制见代码中注释） | true / false |
| timeFormat | 时间格式，显示于图表右下角的时间 | %Y、%Y-%M-%D 等 |
| reverse | 是否倒序 | true / false |
| divide_by | 类型根据什么字段区分？如果是 name，则关闭类型显示 | |
| divide_color_by | 颜色根据什么字段区分？ 须要注意的是，如果配置成 name，则各条颜色不同（因为 name 值各异），如果配置成 type 等，那么相同 type 值的条颜色相同。 | 字段名 |
| color | 指定部分或所有条的颜色，该项与 divide_color_by 设置有关。 | 以 divide_color_by = 'name' 为例，"中国"是其中的一项 name 值，那么该项将显示 #D62728 色： color: { '中国': '#D62728' } |
| changeable_color | 若 true 则颜色的深浅将根据数据的增长率实时改变 | |
| itemLabel | 左边文字 | |
| typeLabel | 右边文字 | |
| item_x | ||
| interval_time | 时间点间隔时间 | 2 |
| text_y | ||
| text_x | ||
| offset | ||
| display_barInfo | 如果希望不显示，则可以设置较大的值，单位像素 | |
| use_counter | ||
| step | ||
| format | 格式化数值 | |
| left_margin | ||
| right_margin | ||
| top_margin | ||
| bottom_margin | ||
| dateLabel_x | ||
| dateLabel_y | ||
| allow_up | ||
| enter_from_0 | ||
| big_value | ||
| use_semilogarithmic_coordinate | ||
| long | ||
| wait | 数据加载完成后开始播放前的等待时间 | 0 |
| update_rate |
确定唯一凭证：
若项目仅提供微信端访问，那么使用微信的授权（即以微信 openid / unionid 作为唯一凭证）是一种体现注重用户体验的方式。如果项目需要应用到多个平台上，那么通过微信来授权变得不那么完美（譬如未安装微信客户端或平台不支持使用微信授权等）。因手机的使用率已明显高于电脑的使用率，再加上用户帐号实名认证的要求，以手机号码为作为帐号的唯一凭证是非常合理的。
登录唤起条件：
当用户打开需要登录授权的页面或触发需要登录授权才能执行的操作时。
场景实现：
平台 | 实现 |
微信网页/小程序 | 授权获取 openid / unionid 同时若未绑定手机号码则强制绑定（发送验证码的方式） 如果允许在微信上登录不同的用户帐号，那么需要提供【“手机号码 + 密码”登录】方式 |
手机 App | 提供【“手机号码 + 密码”登录】 提供【第三方帐号登录】，登录后强制绑定手机号码 参“京东”等 |
PC 端浏览器网页 | 提供【“手机号码 + 密码”登录】 登录框可切换成【扫二维码登录】，登录后强制绑定手机号码 |
手机浏览器网页 | 提供【“手机号码 + 密码”登录】 如果提供【第三方帐号登录】，那么可能需要在网页上手动输入第三方帐号的用户名密码，而非跳转到第三方 App 上（视第三方开放平台） |
l 【“手机号码 + 密码”登录】页面显示填写手机号码和密码框的表单，提供“忘记密码”、“短信验证码登录”、“手机快速注册”等功能。如果在可长期记住登录状态的场景中（如手机 App）也可取消密码，直接使用短信验证码登录。“手机快速注册”必须通过短信验证码实现实名认证。
l 【第三方帐号登录 / 扫二维码登录】App 中提供跳转相应第三方 App（如微信）授权登录，PC 端网页中提供微信扫二维码登录。登录获得 unionid，同时判断是否已经绑定过手机号码，若未绑则强制绑定，确保数据库中的每一条用户信息都有手机号码。
注：同一个微信帐号在不同的公众号和 App 中的 openid 不同，将这些公众号和 App 通过微信开放平台绑定后，同一个微信帐号的 unionid 是相同的，可用于判断同一用户。
流程图：
各平台登录设计：
新项目上线，在 Windows XP 中使用 IE 访问网站，http 正常， https 提示“无法显示网页”，这是因为当前电脑不支持网站提供的 SSL 协议。遂简单整理了各 IE 版本在不同操作系统下 SSL/TLS 的支持情况，表格仅供参考，可能会因特殊情况而有所不同：
| SSL 2.0 | SSL 3.0 | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 | |
| XP - IE6 | 默认支持 | 默认支持 | 可选支持 | 不支持 | 不支持 | 不支持 |
| XP - IE8 | 可选支持 | 默认支持 | 默认支持 | 不支持 | 不支持 | 不支持 |
| Vista - IE7 | 可选支持 | 默认支持 | 默认支持 | 不支持 | 不支持 | 不支持 |
| Vista - IE9 | 可选支持 | 默认支持 | 默认支持 | 不支持 | 不支持 | 不支持 |
| Win7 - IE8 | 可选支持 | 默认支持 | 默认支持 | 可选支持 | 可选支持 | 不支持 |
| Win7 - IE11 | 可选支持 | 可选支持 | 默认支持 | 默认支持 | 默认支持 | 不支持 |
| Win8 - IE10 | 可选支持 | 默认支持 | 默认支持 | 可选支持 | 可选支持 | 不支持 |
| Win8.1 - IE11 | 可选支持 | 默认支持 | 默认支持 | 默认支持 | 默认支持 | 不支持 |
| Win10 早期 - IE11 / Edge | 不支持 | 可选支持 | 默认支持 | 默认支持 | 默认支持 | 不支持 |
| Win10 - IE11 / Edge | 不支持 | 可选支持 | 默认支持 （部分版本 可选支持） | 默认支持 （部分版本 可选支持） | 默认支持 | 可选支持 |
几个注意点：
原文标题：新手还在学习排版配色，高手已经在做内容设计了…
任何事物的呈现和传达都需要通过一定的媒介，在媒介承载的过程中，均会产生损耗。我们设计的目的之一就是将所传达的内容在媒介承载的过程中让损耗降到最低，呈现出我们想要给受众的东西，且能够被快速察觉、理解和获取（主动及被动的）。
文本作为语言沟通的书面化，一直以来承载着大量的信息，也是生活中最常见及熟知的方式。
当前人们快节奏的生活状态、快消的阅读习惯以及注意力分散，所以需要我们通过设计手段来减少视觉、心理及认知压力，让用户能够快速定位、理解和消化。同样，我们也需要根据目标、任务甚至品牌的诉求，从而更好的服务于主题。
以下是工作中一些心得和总结，旨在从更多角度去思考和完善，让文本信息能够得到更好的呈现和传达。
一、前提
前提是做事的先要条件。
达成目标
了解受众
具体情景
二、目的
目的是做这件事的动力。
满足用户所需，帮助完成工作；
简单直接，有效传达；
达成一致，统一规范可实施。
三、角度
角度是考虑要做的内容。
准确性
一致性
易读性
内容调性
1. 准确性
秉持文本信息准确明了、简达明意，无歧义
首先要明确所传达的群体对象，尽量避免使用行话，使用「用户」能直接理解的文本信息，当然相应的专业词汇也应给予良好的解释和说明。
案列：我们将 「循环次数」 更改成 「轮播次数」 ，「循环次数」会让人产生思考（循环一次是播放一次还是两次的），而 「轮播次数」 就显得更加直观明了且更符合上下文的语境。
用词完整、阐述直接
用词完整，例如保存修改，而不是简化为保存；阐述直接，避免模棱两可，模糊不清。
内容传达上应做的良好的「自解释」
例如：涉及操作事件的文本命名应根据上下文准确的进行表达，而不是含糊其辞的，使文本能够准确的解释和表达将要发生的事件及行为。
寻找更加合适的表达方式
例如：未输入提示，「XXX不能为空」 和 「请输入XXX」，第一个在表达上其实有一些责怪，而第二个表达同样说明了意思，但在口吻上却更加温和，并告诉用户应该怎样操作和行动。
避免错别字
错别字只会拉低产品的品质和用户内心的形象，请务必严格检查。避免把 「登录」 写成 「登陆」。
准确应用标点符号
标点符号能够赋予文字节奏，表达语气以及对内容的组织。准确应用，能够帮助文字更加有效传达和被人理解。
2. 一致性
同一事物用词一致，消除重复
例如，涉及新建的操作，一会用「新建」，一会又用「新增」、「创建」或者「添加」；涉及称谓，一会用「你」，一会又用「您」、「我」或者「我的」；涉及帮助，一会用「支持」，一会用「帮助」或者「服务」等等，我们应该消除这些重复，统一用词。
相似场景、意思和语境下句式表述一致
例如，未输入提示，应避免「请输入XXX」和「XXX不能为空」等不同的表达方式。
标点符号规范
根据符号使用规范并结合自身产品情况具体定义。例如：全角和半角，如常见「：」和「:」，截断省略「…」等等。又如：标题，提示文本不加结束符号等。
时间表达规范
时间是一个记录戳，需要根据与当前进行定义，显示不同的格式。
例如：今天发生的（自0时起），显示时分（24h）；今天之前发生的，显示月-日（例如02-12）；跨年，显示年-月-日（例如2017-12-30）。
数字使用规范
例如：统计数据统一使用阿拉伯数字。
大小写使用规范
专有名词大小写，单位符号等。例如：iOS
中西文混排规范
中英文之间需要加空格等。
代称一致
第一人称「我」，第二人称「你」和「您」，具体根据场景进行使用，同场景统一一致。你和您请不要随意混用或均使用，应当统一。
操作名称与目的页面标题一致
常见于移动端，在 PC 常见于链接及导航。
3. 易读性
简化内容，避免啰嗦
简单而直接，避免长段使用短语，保持措辞简洁，让读者感受到阅读乐趣，引诱他们深入阅读。
打破复杂冗长
通过段落、有序列表（项目编号）、无序列表等方式使内容结构化，便于视觉扫描。
段落：根据句意，进行分段呈现。
有序：当项目顺序或优先级重要（程序等）时，使用编号列表。
无序：项目相关时使用项目符号列表，但顺序或优先级无关紧要。
结构化：节奏和韵律。例如，电话号码或者银行卡号，使用连字符或空格使其容易被读取和识别。
重要内容突出显示
让用户首先看到最重要的内容，而不是去寻找它们。
经过良好的排版
合理使用文字大小：使用合理的字体大小，太小太大对于屏幕阅读来说都是低效率的。网页端字体大小一般使用不低于12px，更加直观易辨（对于多数人而言）的字体14px和16px；移动端字体大小不小于10pt（sp），12-18pt（sp）都是常用的字体选择范围。
颜色与对比度：颜色我们需要考虑色彩本身（色相、明度和饱和度）给人直观感受和文化寓意的，以及文本与背景之间是否有足够的对比度，从而方便人们可以更加直观舒服的进行阅读。W3C 建议的视觉呈现文本和文本的图像具有对比度至少为4.5:1，大型文字和图像的对比度至少为3:1，具体详情可了解 Contrast (Minimum):Understanding SC 1.4.3
字间距：汉字属于方块字，原则上文字外框彼此紧贴配置，称作密排；在各字之间加入固定量的空白来排列文字，称作疏排；减少字距，使得文字外框一部分重叠，称作紧排。文字排版时，会根据具体情况对字间距进行调整。大多时候我们对采用疏排方式，增加字间距，以提高易读性。
行高：具有良好的行距的文本，更易阅读和引导用户视线。与行之间的空白称为行距，文字尺寸+行距=行高，行距一般介于文字尺寸的50%–100%之间，自然行高的设置一般为文字尺寸的1.5-2倍。文字尺寸较小时，行高设定也会相对较小。行距一般不会超过文字尺寸，因为这样并不会因此而增加易读性。
段间距：段落与段落之间的距离，段间距大于行间距，行间距一般设置为文字大小的2-3倍之间，合适的段间距能够缓解用户的视线压力，起到很好的节奏及阅读定位。
行字数：一行的文字数量。一行文本过长，用户需要去移动脖子或视角，易造成的眼睛疲惫感，造成阅读困难；此外，在大段文本中找到正确的行也将变得困难。过短视线需要不断换行，从而打断了读者阅读节奏，造成尴尬的断裂效果；行太短也会造成用户在一行没读完的情况下去关注和阅读下一行。
虽然至今汉字依然没有正统的方法和具体行字数来衡量文本的完美长度，个人经验在12px下30-60汉字左右（包含标点），具体也要根据内容、人群等约束和变量，当然最重要的是要相信你自己（专业的设计师）的眼睛和判断。
词语尽量避免同行断开：例如，行末为「跳」，下行开头为「转」，读起来就有断句的存在感。
对齐方式：中文（简体）排版一般遵循左对齐的原则，符合我们从左到右的阅读习惯。文字居中，本身不适合可读性，但可用于许多小段文本块。右对齐在表格设置中，可用于数字的对比等应用。
符号避头尾：中文中行首遇到不能置于行首的标点符号，必须要将移动到前一行行尾。
合理突出：对于关键字、要点通过位置、加粗、比例大小和色彩处理等，以便让用户直接关注到。当然也要控制突出数量，毕竟都是「重点就没有重点」，过多也会扰乱和分散用户的注意力。
链接：链接文本需要很好的说明用户将要去何处，可以使用蓝色或者下划线标示出链接的样式，这是用户熟悉方式。神奇的「下划线」为体验赋能
尽量少用斜体：PC 和无线端的各个官方的中文字体包并没有斜体预设，生拉硬扯的倾斜在一定程度上是影响美观度，并造成一定的阅读困难。如果是为了突出或区别可以考虑使用字重、大小和颜色等方式。
层级处理：有对比就有层级关系，可通过大小、字重、色彩、距离、方向、纹理、形状、背景等等方式，可以让整体排版布局更加富有层次结构，让内容的可读性得到明显的提升。 例如：标题、副标题、引用和内容也是一种层级处理（结合了大小、色彩或者距离等等）。
留白：合适的留白可以更好的烘托内容主题，缓解视觉压力。
数量信息前后有汉字时需加空格：不加空格会出现前后拥挤的视感，另一方面可凸显数字信息。
4. 内容调性
依据产品定位，通过文本表述传递其相应的价值观和情感诉求
任何产品都有所针对的人群及自身的品牌形象。C端产品和 B端产品，儿童产品和成年人产品，所使用的语言表达方式自然也都是不一样的。
依据不同状态和用户群体
根据状态（正面、中性和负面）和用户（新手、中级用户和专家），使用合理的语调及用词规范，以适应不同的情境和状况。
始终坚持积极主动的，而不是消极令人沮丧
「请输入内容」与「错误，内容不能为空」，同样的意思却有不同的感受，从积极的一面表达就是传播正能量。
四、通用产出物
字体
日期和数字
标点符号
大小写
中英文混排
代称
1. 字体
字族 Font-Family
Font-Family 属性设置的字体系列。Font-Family 属性设置多个字体作为一种「后背」机制，浏览器不支持第一种字体，它会尝试下一个字体。
如果字体系列的名称超过一个字，它必须用引号，如Font-Family：「宋体」。
对于依附在 PC 端产品而言，统一的字体规范，以保证在不同平台、不同浏览器下保持良好的美观性和易读性。
以下呈现的是 Ant Design 的字体家族。个人在使用了多款后，觉得最好的一份：
font-family：「Chinese Quote」, -apple-system, BlinkMacSystemFont, 「Segoe UI」, 「PingFang SC」, 「Hiragino Sans GB」, 「Microsoft YaHei」, 「Helvetica Neue」, Helvetica, Arial, sans-serif,「Apple Color Emoji」, 「Segoe UI Emoji」, 「Segoe UI Symbol」;
如果大家想了解字体排列前后顺序的玄机可以认真看《推荐！Web中文字体应用指南》这篇文章。
以下备注区域，是我在使用字族的路上磕磕碰碰所收集到的有限知识，也算知其所以然了，若有不妥、错误和缺漏欢迎指正。
备注区域：
-apple-system：macOS 和 iOS平台的 Safari 调用 SanFrancisco 字体
BlinkMacSystemFont：macOS Chrome 调用 SanFrancisco 字体
Roboto字体，由 Google 开发，是 Android 4.0「Ice Cream Sandwich」及后面Android版本的默认字体。
Segoe UI 取代Tahoma，Windows 从 Vista 开始的界面默认西文字体。利用 ClearType 技术的新字体 Segoe UI 看起来比现在略显僵硬的 Tahoma 更加人性化。
Tahoma 被采用为 Windows 2000、Windows XP、Windows Server 2003及 Sega 游戏主机 Dreamcast 等系统的默认字型。
Arial 是一套随同多套微软应用软件所分发的无衬线体 TrueType字型。
Microsoft YaHei 微软雅黑，该字体将作为 Windows Vista 的默认字体取代2001年推出的 XP系统下默认的宋体汉字，以支持高清显示的 ClearType 功能。
Simsun 宋体，一直是简体中文版 Windows XP系统及之前版本的默认字体。但由于字体的特性，在Windows Vista 中已经改用支持 OpenType 的微软雅黑，
HanHei SC 威锋瀚黑，现苹果简体中文，OS X 10.11 El Capitan 开始，
STHeiti 华文黑体，分为「黑体-简（Heiti SC）」和「黑体-繁（Heiti TC）」，OS X 10.6 Snow Leopard 直至 OS X 10.10 Yosemite。
Hiragino Sans GB 冬青黑体
STXihei 华文细黑，是苹果公司 Mac OS X9 以及之前版本的操作系统的中文默认字体，截至 OS X 10.5 Leopard。
PingFang SC 为 iOS9.0 以后系统自带中文字体。
SanFrancisco iOS9 正式发布之后，替换了之前的 Helvetica Neue 成为了 iPhone/iPad 系列设备的默认字体。
Myriad Set Pro 苹果向 adobe 公司定制了一款西文字体，是以 myriad 为原型的，完成后在市面上叫做「myriad set」，后期升级为「myriad set pro」。
Helvetica Neue 意为「新 Helvetica」
Helvetica 是苹果电脑的默认西文字体
sans-serif 并非一个具体字体，而是css的通用字体族，具体是什么字体是由浏览器设置决定的。
字号 font-size
标题，内容，注释说明等不同字号的大小。
字间距 letter-spacing
根据不同字号，及文本数量进行字间距定义。
行高 line-height
设置行高能很好的解决，缓和上下文本之间拥挤在一起的情况。
颜色 text-color
这里主要讲下注意对比度的问题，很多产品在这一点上都忽视了这一点，搞出了所谓的「小清新」。
你可以查看完整的《网页内容可访问性指南WCAG 2.1》
《掌握具有共享样式的文本系统》（搭梯子访问）
2. 日期和数字
日期
使用完整数字日期，如：2018-01-02。
时间
使用24小时制，如 13:01:29
具体到时分秒，如当前对话显示 09:01:02
使用半角 「:」
日期和时间之间包含一个空格，如 2018-09-01 13:01:20。
数字
使用阿拉伯数字。
对四位或更多位数的数字使用逗号。
对手机号码使用前后无空格的连字符「-」。不要使用点，空格等其他符号。
数字范围使用前后无空格的连字符「-」。
正负数后不加空格。
数字和字符之间不需要空格
货币
人民币符号（¥）在数字前面，精确到小数点后两位。
测量单位
储存单位（B、kB、MB、GB、TB），在数量和度量单位之间包含一个空格。
对于长度「毫米（mm）、厘米（cm）、分米（dm）、千米（km）、米（m）、微米（μm）、纳米（nm）等」和重量「千克（kg）、克（g）、毫克（mg）、微克（ug）等」等测量单位应为小写（电流单位除外）。在数量和度量单位之间包含一个空格。
屏幕单位「像素（px）、逻辑分辨率（pt、dp、sp）、英寸（in）等 」应为小写。在数量和度量单位之间包含一个空格。
在连续列出尺寸时，将度量单位放在末尾，而不是在每个数字之后，并包括一个空格。
在所有情况下，数字和单位之间包含一个空格。HTML代码的最小空间是 & hairsp; 或 & #8202;
测量单位分为基本单位和导出单位。国际单位制共有7个基本单位长度：
长度：米 m；
质量：千克（公斤） kg；
时间：秒 s；
电流：安[培] A；
热力学温度：开[尔文] k；
物质的量：摩[尔] mol；
发光强度：坎[德拉]cd；
并由物理关系导出的单位称「导出单位」 。
3. 标点符号
省略不必要的标点
标题、副标题、输入框下的提示文本、输入框占位符、悬停提示中的文本、Toast中、弹窗等短句，在遣词造句时尽量避免标点符号，始终末尾不要使用句点。
有序列表和无序列表
使用冒号引入项目列表，列表后不使用标点。
使用列表来表示步骤、组或信息集。简要介绍列表的上下文。在顺序重要时列出数字列表，比如当您描述流程的步骤时。当列表的顺序不重要时，不要使用数字。
常用标点符号规范
空格：链接与前后文本之间增加空格；数字和单位之间包含一个空格；电话号码与前后文本包含一个空格；
省略号「…」：半角省略号，超出截断代替省略文本；
星号「*」：半角星号。表单必填、说明备注；
连接号「-」：半角连接号，前后无空格，如2018-01-04，2008-2018；
冒号「:」：半角冒号，用于时间的表示，如16:45 ；
冒号「：」：全角冒号，用于表单；
破折号「——」：中文破折号占两个汉字空间；
书名号「《》」：产品中常用于法律条文。
相关推荐：
4. 大小写
专门名词大小写
文件格式
当一般引用文件扩展名类型时，全部大写而不包含句点。
GIF
PDF
HTML
JPG 格式
引用特定文件时，文件名应该是小写的：
内容策略-设计完全手册.pdf
皮皮虾.gif
西湖.jpg
hot.html
5. 中西文混排
中英文之间需要加空格
中文与数字之间需要加空格
中文为主，使用全角符号且与英文或数字之间不加空格
6. 代称
为了表达双方的平等，避免使用「您」。使用「你」代称客户/用户，借以表达客户的口吻。在客户/用户为主的情况下使用「我」。避免同一句子中混用「你」和「我」。
对于「您」还是「你」的使用并非绝对，主要看行业以及服务的对象
在《胜于言传-Web内容创作与设计的艺术》中作者建议：
当用户提问的时候：
在问题中使用「我」和「我的」（用户的声音）
在答案中使用「你」和「你的」（应用对用户说话）
用「我们」和「我们的」代表回答公司
当应用提问的时候：
在问题中使用「你」和「你的」（应用向用户提问）
在答案中使用「我」和「我的」（用户的声音）
用「我们」和「我们的」代表回答公司
五、指导建议
操作行动
文本说明
句式结构
语音和语调
写作建议
1. 操作行动
按钮
清晰可预测。应该能够预测当点击按钮时会发生什么。
行动号召。按钮应始终带有强烈的动词，鼓励行动。为了给用户提供足够的上下文，在按钮上使用 {动词} + {名词} 格式，除了保存，关闭，取消或确定等常用操作。
以下是常用词的含义，以避免不恰当或混淆使用：
所有具体的用词需结合场景和生活习惯。
链接
使用描述性的链接文本。切勿使用「点击这里」或「这里」作为链接文本。
如果一个链接出现在句子的末尾或逗号之前，不要链接标点符号。
链接使用蓝色，这是用户习以为常的认知，并明确区分点击和未点击的区别。
2. 文本说明
对操作说明，功能说明，名词（术语）解释，提示信息等进行用户测试，是否明白其意，记住这是一个不断优化的过程。
以下是产品内的主要文本：
操作文本：按钮；
导航文本：全局和局部导航、目录、链接；
说明文本：功能说明、术语解释；
提示文本：弹框、toasts、操作反馈、系统反馈、通知等；
操作说明：功能引导说明，操作文档；
标题和副标题：弹框标题、操作说明标题、法律条款标题等；
条款：法律条款、申明；
ALT：为图片添加文字说明。
3. 句式结构
通用场景下的语句可进行归纳在一起，形成统一的句式结构。
例如：
操作反馈：成功直接提示结果，失败显示结果+说明原因+如何解决。
二次确认：先说明利害，再询问是否操作。
标题：「动词」+ 「名词」格式等。
4. 语音和语气
这听起来是谁，什么样的语音和语气能代表我们，我们想传达什么的形象。
因此，你可以建立一套准则，一般而言准则应该：
基于产品当前的业务；
准则可被执行，避免过于空洞；
易于记忆，3-5个尚可；
并随着产品发展和愿景的变化而不断适应改进。
例如：
积极主动
始终坚持积极主动的，而不是消极令人沮丧。
自信专业
避免听起来傲慢、亲密、孩子气或其他不适当的或非正式的。
友好尊重
依据不同状态（正面、中性和负面）和用户群体（新手、中级用户和专家），使用合理的语气及用词规范。
5. 写作建议
个人写作过程中的一些小感悟：
好的结果是不断修改来的，修改的基础是要先写下来，所有先记录而不是停留在脑子里，这才是一切开始的基础。
记住用户很忙且没有耐性，甚至不聪明，这会不断的促使你修改调整。
找人阅读并呈现结果，并询问其含义和建议。这是检验的最佳实践。
过段时间再来看看，或许有更好的方式。
结尾
这并非是一个完整的（内容层面可能保存图片风格，插画图标等），还有很多地方可以补充。重要的是找到适合你的产品，并有这样的意识去不断优化你的产品内容，从而更好的服务你的用户。