Blog

• 个人随笔
• 阅读
• 博弈
• OKR的陷阱与助力
• 武汉小龙虾市场提供加工服务了
• 走走停停
• 观影
• 某厂商防止DNS拦截的办法
• Google翻译API的使用教程
• 调研
• 社区规则分析
• 亚马逊商店社区规则
• huawei
• 疑难杂症
• Windows Server 2019长时间运行ipv6断连问题
• openvpn网络不通
• Windows桥接时的IPv6问题
• 宝塔docker源加速
• Windows Edge浏览器卡顿的一种解决办法
• 程序员
• 网络
• 电信IPv6的一些特征
• 为什么不应该把TCP思维套在UDP上
• linux网络问题定位
• 如何提升自建DNS服务下的网络体验
• ChatGPT VPN识别绕过方法
• 杂谈
• 第三方库的陷阱
• 方案设计模板
• 命令行语法约定
• 命令行手册中括号的含义
• 华为C++编程规范
• 问题定位
• OS
• linux
• linux导览
• windows
• 理解Windows网络_WFP
• 理解Windows事件跟踪_ETW
• wireguard配置
• Windows阻断网络流量获取
• Windows防火墙管理-netsh
• Windows相关资源
• Windows导览
• windows-ipv6管理
• window-message
• Win-to-go
• environment
• 虚拟内存磁盘配置
• wsl
• vs-remote-debug
• vscode
• 设计模式究竟有几个原则
• 多平台内容发布工具--蚁小二体验
• 简书的创作体验
• 工具
• 微信读书体验分享
• 微信读书自动打卡刷时长
• 关闭独显以省电
• docker
• docker介绍
• adguard
• 利用DNS服务平滑切换网络服务
• 测试工具
• 简易server-client代码
• AI
• Copilot系列
• 安全
• 避免博客泄露个人信息
• snort
• 可信设计
• 华为可信概念
• 华为内网网络安全分析
• DoS防范

个人随笔

随笔就是随便写写, 简短的, 未经严肃思考推敲的, 临时起意的, 无关紧要的胡思乱想.

一些技术博客要写定义, 写前因后果, 篇幅会比较长, 写的很累, 也很费时间.

简短的技术博客也会放在这里, 但是不会写太多背景, 在随笔写的东西都会比较轻松.

阅读

• _index

博弈

OKR的陷阱与助力

OKR 的陷阱与助力

2009 年，哈佛商学院发表了一篇名为《疯狂目标》（Goals Gone Wild）的论文。文章用一系列例子解释了“过度追求目标的破坏性”：福特平托（Pinto）汽车油箱爆炸、西尔斯汽车维修中心的漫天要价、安然公司疯狂膨胀的销售目标，以及 1996 年造成 8 人死亡的珠穆朗玛峰灾难。作者提醒说：目标就像是“一种需要谨慎使用和严密监管的处方药”。作者甚至还提出这样的警告：“由于聚焦过度、出现不道德行为、冒险行为增多，以及合作意愿和工作积极性下降等原因，目标会在组织内部引发系统性问题。”目标设定的坏处可能会抵消其所带来的好处，这就是这篇论文的观点。

读"这就是 OKR"

在前公司实践过 3 年 OKR, 恰逢新公司现在也要转向 OKR, 老板推荐了这本书这就是 OKR. 花了两周时间才断断续续看完, 简单且主观的分享一点未深思的观后感.

OKR, 原文 objectives and key results, 直译是目标和关键性结果.

按照谷歌的 OKR 模式, 目标可以分为两种, 承诺型目标, 和愿景型目标. 对待两种类型目标会有不同评价方式. 目标的设立需要仔细思考, 可以参考原书最后一章资源 1 谷歌公司的内部 OKR 模板 或者 这个链接, 对照阅读.

对关键性结果的设立也需要好好思考, 可以把这个词理解为一个里程碑, 每一次前进时, 朝着最近的里程碑前进, 最终达到目标. 这个里程碑是建议能用数字衡量的, 以此判断自己达到目标与否, 分析产生差距原因.

由于 OKR 里的关键性结果仍然建议能用数字衡量, 那么它和 KPI 的区别在哪. KPI 是 key performance indicator, 关键绩效指标. 很明显, KPI 没有明确的包含目标.
不考虑目标, 盲目的下发数字任务对企业产生伤害有许多的案例, 书中会举很多例子.

除了解释和推销 OKR, 还有一个很重要的工具, 在书的偏后段提出, 那就是持续性绩效管理, 使用工具是 CFR, 也就是 Conversations, Feedback, Recognition, 即交流,反馈,认可.
主要介绍的是主管找普通职员进行交流, 得到反馈, 并且认可他们的表现. 这里话虽好听, 实际场景里, 由于对不同人的工作无法完全的了解, 误会和自以为是总会出现, 因此, 书中推荐更多的进行交流. 什么是"更多"并没有明确的指标. 如何避免"交流"变为"施压", “反馈"变为"抱怨”, “认可"变为"PUA”, 需要交流双方都具有一定的沟通技巧.

此书的下篇提到的持续性绩效管理, 字面上看和绩效管理更像了, 同时书中多次郑重强调, OKR 的完成度绝不能与薪资待遇挂钩, 否则会导致数字失真, 走回 KPI 伤害企业的老路.
那么实践 OKR 后, 什么指标会影响员工的收入呢, 书中没有给出答案. 按我自己的理解, OKR 相较绩效主要多出目标这个维度, 那么有可能这个目标和公司整体的利益越相关, 越有利于个人的升职加薪. 因此个人在设立目标时, 应该考虑公司的利益, 并且把目标设置为最大化利益的目标. 避免设置为个人利益, 而不利于公司的, 比如考取证书, 锻炼身体, work&life balance. 虽然有点滑稽, 但是见过不少走错路的朋友.

粗暴的绩效管理会伤害企业, 本来是一件可以预期的结果, 反而好奇为什么很多企业坚持使用了 KPI 多年, 它们如今的经营状况如何. 有许多决定并不太经得起推敲, 如果几个逻辑优秀的人在一起好好讨论, 沟通交流, 就更有可能做出更正确的决定.

总结

按照我一贯的标准, 举例子目的应是帮助理解, 不能用于证明观点, 只能证反观点.
此书有以下缺陷:

• 在证明 KPI 失败上举了一些案例, 但不能证明 KPI 一无是处, 也不能证明凡是有 KPI 的地方都可以通过替换为 OKR 来达到成功.
• 为证明 OKR 有用, 例举了一些成功的企业做出的部分正确的选择, 但是使用了 OKR 仍然失败的企业更是数不胜数, 如果说失败者们是因为"心不诚"才会失败, 那么 OKR 只不过是另一个玄学而已.
• 企业的成功依赖很多因素, 例如经营状况, 员工的绩效, 客户的满意度, 客户的支持度等等, 没有哪一项为决定性因素.
• 存在一些断言, 但是不能证明它们是正确的, 孤立的案例无论成功与否都不能说明什么, 因此不是一本较严谨的书.

虽然书不太严谨, 但从阅读此书中我也仍然有收获, 或许本来就是我自己的想法, 那就是合作的人需要更多的交流, 将透明作为企业文化, 促进众人齐心协力, 这样就可以集到一张"人和"卡.

参考资料

• google-okr-playbook
• a-typical-okr-cycle

武汉小龙虾市场提供加工服务了

武汉的小龙虾市场现在提供处理服务了, 买虾后, 虾摊旁提供免费的虾清洗和处理服务, 有三个人一同处理.

第一批提供虾处理服务的商家, 可以立即获得一些利益, 吸引购买者, 毕竟这是典型的"人无我有“的优质服务.

但是, 该服务门槛较低, 任何商家叫上三个人都可以提供, 而代价却很高, 毕竟虾处理服务占用了三个劳动力. 如果不能抢占足够多的市场, 这个服务迟早成本高于获利.

只要商贩在这个夏天长期的贩卖小龙虾, 最终会发现这个服务的代价远远高于收益, 但是却无法停止, 因为这个服务已经成为了他们的卖点, 他们的客户已经习惯了这个服务, 一旦停止, 客户就会流失. 你可以一开始就不给客户提供这个服务, 但很难在提供免费服务后撤回.

有的人做生意会讲究一个”多给一点", 这种策略自然比"少给一点"更受消费者欢迎, 但它无形中增加了商家的成本, 让商家们陷入低意义低门槛的竞争中, 最终大家都挣不到钱而行业枯萎. 所以有些行业到底是因为服务差而没落, 还是因为服务好而没落, 这个问题值得深思.

许多大企业也有类似亏本赚吆喝的行为, 其目的乃是为了垄断, 直至有一天市场长只有一家打车, 只有一家团购, 这一天才是到了收割的时候. 但我们也可以发现, 它们都不急于收割, 而是通过算法只收割部分人. 一方面赚取定价权带来的超额利润, 另一方面, 使用新产品的低定价对新入场者围追堵截, 防范每一个潜在的竞争对手. 这些大企业已形成事实上的垄断, 韭菜割不割只是时间问题.

我们在工作中也会遇到不少"卷王", 很难评估他们是否带来了更多价值, 但能他们明确能做到的就是永远比别人晚下班半小时, 一旦俩卷王较上劲了, “多给一点"互锁, 全办公室都得笼罩在其阴影之下. 他们靠着这种低质的服务, 挤压着正常打工者的生存空间. 比的既不是创新, 也不是业绩, 主打的就是"卖苦力”, 却能获得老板的青睐, 这显然是一种不正常的恶行竞争.

最后再说回小龙虾市场, 有人能垄断定价自行定价, 有人能垄断货源专供高端, 而谁能通过垄断打工而自发打工呢?

走走停停

• _index

观影

某厂商防止DNS拦截的办法

近日发觉 DNS 公共服务有 IP 有异常访问行为, 每秒数十次重复的请求一个域名, 完全不遵循 DNS 协议, 不理会全局生存时间 (TTL)值.

开始时以为该 IP 是攻击者, 观察流量后发现, 主要是某厂商的 App 在疯狂请求 DNS. 后端设置的TTL=10表示接收到的 DNS 查询返回值生命周期为 10 秒, 这 10 秒内请求者都应该使用这个返回值, 而不是再次请求 DNS 服务器. 但该 App 每秒数十个相同请求, 说明该 App 没有按照 DNS 协议正确处理 TTL 值. 后台拦截请求统计里, 有 90%以上的请求都是该域名的请求.

可能该厂商知道有 DNS 拦截的手段, 采取了你不让我访问, 我就让用户 App 直接 DoS 攻击你的 DNS 服务器的方式. 由于后端同时设置了每秒只允许 20 次突发请求, 该莽撞行为同时会影响到用户的其它正常 DNS 查询, 影响其它 App 的正常使用.

运维看到这样单 IP 疯狂请求同一域名的行为, 不想放行也得放行了.

Google翻译API的使用教程

如果你需要使用 API 自动化翻译工作, Google 翻译 API 是一个不错的选择. 它相较 DeepL 翻译质量可能略逊一筹, 但具有更好的性价比, 特别是每月有 50w 字符的免费额度.

产品介绍

Google 翻译大家都用过, 这里介绍的是它的 API 服务, 全称叫做 Google Cloud Translation. 通过 API, 可以实现批量翻译, 自定义翻译模型, 翻译文档等功能.

价格

每月 50w 字符免费额度, 超出部分按字符计费.

基本版和高级版的区别

开始使用

• 创建或选择项目

• 启用 API, 如果没有启用结算功能, 这里会提示增加结算账户, 需要外币信用卡

• 使用 REST 时进行身份验证
  • 安装 gcloud CLI
  • 生成 gcloud CLI 凭据

    $cred = gcloud auth print-access-token
    $project_id = "example"
    $headers = @{ "Authorization" = "Bearer $cred" }
    Invoke-WebRequest `
        -Method GET `
        -Headers $headers `
        -Uri "https://cloudresourcemanager.googleapis.com/v3/projects/${project_id}" | Select-Object -Expand Content

• 试用

    $cred = gcloud auth print-access-token
    $project_id = "example"
    $body = @{
        "sourceLanguageCode" = "en"
        "targetLanguageCode" = "zh"
        "contents" = @("Hello, world!")
        "mimeType" = "text/plain"
    }
    $body = $body | ConvertTo-Json
    $headers = @{
        "Authorization" = "Bearer $cred"
        "Content-Type" = "application/json; charset=utf-8"
        "x-goog-user-project" = $project_id
    }
    Invoke-WebRequest `
        -Method POST `
        -Headers $headers `
        -Uri "https://translation.googleapis.com/v3/projects/${project_id}:translateText" `
        -Body $body | Select-Object -Expand Content

Linux 使用 curl 命令

    export CRED=$(gcloud auth print-access-token)
    export PROJECT_ID="example"
    export SOURCE_LANGUAGE_CODE="en"
    export TARGET_LANGUAGE_CODE="zh"
    export CONTENTS="Hello, world!"
    export MIME_TYPE="text/plain"
    curl -X POST -H "Authorization: Bearer $CRED" -H "Content-Type: application/json; charset=utf-8" -H "x-goog-user-project: $PROJECT_ID" -d "{
        \"sourceLanguageCode\": \"$SOURCE_LANGUAGE_CODE\",
        \"targetLanguageCode\": \"$TARGET_LANGUAGE_CODE\",
        \"contents\": [\"$CONTENTS\"],
        \"mimeType\": \"$MIME_TYPE\"
    }" "https://translation.googleapis.com/v3/projects/$PROJECT_ID:translateText"

至此, 你已经可以使用 Google 翻译 API 进行批量翻译了.

用途参考

• 翻译网站或应用
• 训练自定义翻译模型
• 为视频添加不同语言的字幕
• 使用不同语言为视频配音
• 翻译有格式的文档
• 实时翻译客户互动内容

扩展阅读

• Cloud Translation 文档入口
• 向 Cloud Translation 进行身份验证
• 使用 API 密钥进行身份验证
• 源语言和目标语言使用 ISO-639 代码标识
• 自定义翻译概览

后记

Google 翻译的官方文档冗长, 实现同一功能有多种不通方式, 在认证和调用步骤有多种途径实现, 本文只选取普通用户最建议和最简单的使用方式, 以供参考.

• 认证种类中选择了本地认证(gcloud CLI)
• 使用方式中选择了 REST API (Curl/Invoke-WebRequest)
• 基本版和高级版中选择了高级版

这是原文发布在blog.jqknono.dev的原创文章, 未经许可不得转载

调研

社区规则分析

• 社区规则分析

亚马逊商店社区规则

亚马逊商店社区规则

huawei

疑难杂症

Windows Server 2019长时间运行ipv6断连问题

我的Windows Server 2019不怎么关机, 在电信/红米路由下, ipv6每次更新时, 本地ipv6连接都会显示无Internet访问权限, 重启设备或者开闭IPv6功能可以解决, Linux下不会出现这样问题.

考虑自动化操作，用这两条命令解决:

Set-NetIPInterface -AddressFamily IPv6 -ifAlias Ethernet -RouterDiscovery Disabled; 
Set-NetIPInterface -AddressFamily IPv6 -ifAlias Ethernet -RouterDiscovery Enabled;

你可以看到命令只是让Windows更新了路由, 不知道为什么Windows没有自动更新路由.

如果有人碰到相同问题可以参考, 如果有更好的解决办法, 也欢迎讨论.

openvpn网络不通

• openvpn配置

openvpn配置

工具脚本

openvpn-install

Windows防火墙配置

New-NetFirewallRule -DisplayName "@openvpn" -Direction Inbound  -RemoteAddress 10.8.0.1/24 -Action Allow
New-NetFirewallRule -DisplayName "@openvpn" -Direction Outbound -RemoteAddress 10.8.0.1/24 -Action Allow

Windows桥接时的IPv6问题

• Windows桥接时的IPv6问题

• WindowsServer 桥接时的 IPv6 问题

现在很多用作软路由的机器硬件配置较好, 仅安装一个 openwrt 大材小用, 基本都会自己折腾一下去榨干它的价值. Linux 的难点在于命令行, 其实命令行用的多的能感受到这也是 linux 的容易之处.

外网访问需求基本爱折腾的人都会遇到, 考虑到 linux 不太有专业的人维护, 安全补丁更新较慢, 衡量后会有部分人决定使用 Windows Server 系统. 原本 openwrt 上的软件则使用 wsl 加 docker 方式运行, 所有需求都可以同样满足.

在 Windows(Server)桥接多个网络时, 会出现 IPv6 地址无法更新的问题, 但是 IPv4 可以正常访问. 由于 IPv6 的地址是运营商自动分配的, 无法手动修改, 所以需要修改桥接的网络配置.

参考

• Network Bridge for ipv6

Generally, bridging is purely layer 2 so no IP address is required, so just like an unmanaged switch should be iPv6 capable.

However, if you can plug the bridge into a switch and more than one client at a time can have internet access through the bridge, then IPv6 will most likely only work with one of the clients because the main router handling IPv6 connections can only see the bridge’s MAC address. I’m not sure how SLAAC decides which client gets the IPv6 but you could test this out with a switch.

DHCP is of course for IPv4. It may be possible to use stateful DHCPv6 to assign DUIDs to each client and make this work but I have no idea how this would be done. Good luck!

解释下, 由于桥接是二层的, 所以不需要 IP 地址, 但是如果桥接的网络连接到交换机, 交换机上的路由器只能看到桥接的 MAC 地址, 无法分辨出桥接的多个设备, 所以只能给其中一个设备分配 IPv6 地址.

• 请问 windows 多网卡卡如何实现交换机功能

一份标准可联网的配置如下:

PS C:\Users\jqkno> netsh interface ipv6 show interface "wi-fi"

Interface Wi-Fi Parameters
----------------------------------------------
IfLuid                             : wireless_32768
IfIndex                            : 24
State                              : connected
Metric                             : 45
Link MTU                           : 1480 bytes
Reachable Time                     : 29000 ms
Base Reachable Time                : 30000 ms
Retransmission Interval            : 1000 ms
DAD Transmits                      : 1
Site Prefix Length                 : 64
Site Id                            : 1
Forwarding                         : disabled
Advertising                        : disabled
Neighbor Discovery                 : enabled
Neighbor Unreachability Detection  : enabled
Router Discovery                   : enabled
Managed Address Configuration      : enabled
Other Stateful Configuration       : enabled
Weak Host Sends                    : disabled
Weak Host Receives                 : disabled
Use Automatic Metric               : enabled
Ignore Default Routes              : disabled
Advertised Router Lifetime         : 1800 seconds
Advertise Default Route            : disabled
Current Hop Limit                  : 64
Force ARPND Wake up patterns       : disabled
Directed MAC Wake up patterns      : disabled
ECN capability                     : application
RA Based DNS Config (RFC 6106)     : enabled
DHCP/Static IP coexistence         : enabled

修改设置方法: netsh interface ipv6 set interface "Network Bridge" managedaddress=enabled

宝塔docker源加速

宝塔 8.2 及以下版本设置 docker 源加速无效, 并且界面上手动设置配置文件内容无效.

这是由于 docker 配置文件位于/etc/docker/daemon.json, 该文件及其文件夹默认不存在, 直接修改文件不会保存成功.

只需要执行mkdir /etc/docker, 然后再在界面上修改加速配置即可生效.

Windows Edge浏览器卡顿的一种解决办法

浏览器版本

122.0.2365.80+

卡顿现象

• 打开个人 profile 时卡顿
• 打开和搜索存储密码时卡顿
• 新建和关闭 tab 时卡顿
• 在新建的 tab 中输入字符时卡顿

目前发现仅中文版 Windows 系统会出现此类型的卡顿.

解决办法

中文浏览器设置路径: 隐私-搜索-服务 -> 地址栏和搜索 -> 搜索建议和筛选器 -> 搜索筛选器, 关闭搜索筛选器.

英文浏览器设置路径: Privacy search and services -> Address bar and search -> Search sugesstion and filters -> Search filters, TURN OFF Search filters.

程序员

网络

• 网络

网络

• 绕墙
  • [wireguard对抗运营商]
• 网络问题定位
  • [linux网络问题定位]
  • [windows网络问题定位]

电信IPv6的一些特征

• 电信IPv6的一些特征

• 电信 IPv6 的一些特征

国内已经全面铺开 ipv6 使用, ipv6 地址池足够大, 个人的每个设备都可以获取到一个 ipv6 地址.
家庭用户使用时需要全栈设备都支持 ipv6 才能最终使用到 ipv6, 由于已经推了很多年, 目前来说 2016 年以后买的设备基本都支持 ipv6 了.

全栈设备包括: 城域设备->小区路由->家庭路由(光猫,路由器)->终端设备(手机,电脑,电视等)

这里不讨论标准的 ipv6 协议, 只讨论电信的 ipv6 的一些特征.

地址分配

首先是地址分配方式, ipv6 有三种分配方式: 静态分配, SLAAC, DHCPv6.
湖北电信使用的是 SLAAC, 也就是说电信的 ipv6 地址是由设备自动分配的, 由于电信的 ipv6 地址池足够大, 所以不会出现地址冲突的问题.

电信 ipv6 地址是随机分配的, 24 小时后重新分配. 如果要从外部访问, 必须使用 DDNS 服务.

防火墙

目前可以发现常见的80, 139, 445等端口已对齐 ipv4 防火前已经都封了, 这非常容易理解, 运营商级的防火墙确实能保护到缺乏网络安全意识的普通用户. 2020 年时电信 ipv6 都是开放的, 现在已经封了一些常用端口.

443端口在电信网内偶尔开放, 但对移动联通不开放. 开发者应注意这一点. 在开发环境测试好的服务, 甚至电信网路手机也能访问, 但移动手机网络却访问不了.

基于简单的防火墙测试, 建议开发者牢记对运营商防火墙的不信任, 选择一个5 位数的端口提供服务.

另外, 电信防火墙没有屏蔽22端口, Windows 的远程桌面服务端口3389也没有屏蔽.
也就是可以远程登录控制, 这会导致一些风险.

攻击者获取到 IP 或者 DDNS 域名后, 就可以开始展开针对攻击, 利用暴力破解的方式获取到密码, 从而获取到控制权, 域名也会暴露一些个人信息, 例如姓名, 住址等, 也可能利用社会工程学的方式获取到更多信息以加快破解速度.

建议关闭 ssh 的密码登录, 仅使用密钥登录, 或者使用 VPN 的方式进行远程登录, 或者使用跳板机的方式进行远程登录.

为什么不应该把TCP思维套在UDP上

• 为什么不应该把TCP思维套在UDP上

为什么不应该把 TCP 思维套在 UDP 上?

结构差异

TCP 上的概念很多: 建立通路, 资源使用, 数据传输, 可靠传输, 基于重复累计确认的重传, 超时重传, 校验和, 流量控制, 拥塞控制, 最大分段大小, 选择确认, TCP 窗口缩放选项, TCP 时间戳, 强制数据递交, 终结通路.

以上这些能力, UDP 基本上都没有, 它仅比链路层多一点区分应用层目的的能力. UDP 足够简单意味着足够灵活.

如果可能发生,则一定会发生

墨菲定律:

如果有多过一种方式去做某事，而其中一种方式将导致灾难，则必定有人会这样选择。

通常介绍 UDP 适合应用在游戏/语音/视频等场景, 少量的错包不影响业务. 为什么 UDP 适合这些场景? 它能用在这些场景, 不代表它是这些场景的最优方案, 必然是存在 TCP 无法解决的问题, 才让这些服务选择了功能简陋的 UDP 协议. 错包不影响业务扩展开来讲是指 TCP 协议在乎错包, UDP 不在乎错包, 更在乎实时性/连续性. UDP 的特点就是它不在乎 TCP 在乎的因素, 这些因素影响了实时性.

在代码实现上, UDP 只需要创建一个 socket, 绑定到一个端口上, 即可以开始收发. 通常 socket 用完时, 端口也用完了.

因此我可以这样使用 UDP:

1. 往任意 IP 的任意端口发送随机报文, 看看哪个端口有响应
2. 甲通过 A 端口, 将请求报文发送到乙的 B 端口; 乙将响应报文用 C 端口, 发给甲的 D 端口
3. 甲通过 A 端口, 将请求报文发送到乙的 B 端口; 乙委托丙将响应报文用 C 端口, 发给甲的 D 端口
4. 甲通过 A 端口, 将请求报文发送到乙的 B 端口, 但将发送报文的源 IP 修改为了丙的 IP, 乙将会将响应报文发往丙
5. 双方协商各用 10 个 UDP 端口, 同时进行接受和发送

这些方法在 TCP 里自然是行不通的, 但在 UDP 协议中, 只要可以这样做, 就一定会有人这样做. 所以当把 TCP 的一些思维套在 UDP 上是一种理想主义, 真实情况常常不是我们能枚举完的.

UDP 的报文非常简单, 使用也非常灵活, 原本没有连接的概念, 需要自己定义 UDP 连接. 尝试了一些定义方法, 都不能完全准确达到连接方向判断意图, 这时需要接纳一些容错, 毕竟原本就没有 UDP 连接的定义, 当各方对 UDP 连接的定义不一致时, 必然会导致行为与预期不一样.

客户端视角的 UDP

语音/视频等业务常会产生丢包, 但是丢包方式的不同对业务有着不同的影响. 比如 30%的丢包是均匀发生的, 还是全丢在某个时间段, 对体验的影响有明显的区分. 显然, 我们期待的是更均匀的丢包. 可是 UDP 没有流量控制防止方法, 如何丢包则有一些方法. 尽管 UDP 通信常被描述为"尽力而为", 但是不同方式的"尽力"会达到不同的效果.

服务商视角的 UDP

如果是 TCP 攻击, 客户端需要一定的开销, 创建连接, 维护连接, 也就是攻击者需要付出一定的代价. 而在 UDP 攻击中, 攻击者付出的代价小很多, 如果攻击者想消耗的就是服务方的带宽流量, UDP 是一个很好的方式. 比如说服务购买了 100GB 的不限速流量, 处理能力仅 10MB 每秒, 但接受速度 1GB 每秒, 那么 90%的请求流量无效, 但这些流量不是免费的. 服务方应该避免产生这种情况.

运营商的视角的 UDP

完成一次通信需包含多个终端以及通信通道, 受关注的总是服务端和客户端, 其实运营商的视角同样重要. DDoS 攻击中, 我们常关心服务端的资源消耗情况, 实际上运营商的资源也是有限的, 服务端简单不响应请求, 但接收流量却已经消耗了带宽, 只是这个资源一般属于运营商. 我们在压力测试中常用到"丢包率"指标, 这个指标表达的完整通信链条中的丢包, 而不仅仅是服务端的丢包. 运营商也会丢包. 在运营商看, 服务方仅购买了 1MB/s 的带宽, 但客户端以 1GB/s 的速度发送, 双方都不必为浪费的流量付费, 是运营商承担了这部分带宽的代价. 因此, 运营商必然想办法屏蔽这种流量, 也就是 UDP 的 QoS. 在 TCP 中有拥塞控制, 但在 UDP 中, 运营商可以通过丢包来控制流量. 实际情况中, 运营商更加简单粗暴, 直接屏蔽长时间使用的端口的流量, 也就是 UDP 的端口屏蔽. 在微信通话的实际测试中发现, 每一通电话客户端会使用多个端口, 其中有一个 UDP 端口会和同一服务器的 6 个 UDP 端口进行通信, 推测就是为了应对运营商的端口屏蔽.

总结

UDP 的灵活表示在实现一个目标时, 它有着多种实现方式, 并且都是合法的, 只要能最终实现稳定的通信, 不管它实现的如何和 TCP 大相径庭, 都是"存在即合理"的. 因而, 我们不能完全将 TCP 的概念套用在 UDP 上, 即便为了产品设计, 创造了新的 UDP 连接定义, 也应该能预期并允许出错, 毕竟"允许出错"就是 UDP 的核心功能, 这是 UDP 的优势, 不是它的缺点, 是服务主动选择的协议核心能力, 而不是不得不接受的缺点.

更多阅读

• 2 万字带你学习 Qos 原理
• 传输控制协议
• 用户数据报协议

linux网络问题定位

排障工具

如何提升自建DNS服务下的网络体验

网络质量和网络体验

什么都不做, 即可以获得最好的网络体验

需要明确, 这里网络质量和网络体验是两个不同的概念. 通信是一个过程, 涉及多个设备, 我们可以称单个设备的上下行表现为网络质量, 而整个端到端的通信表现, 我们可以称为网络体验.

如何衡量网络质量

衡量网络质量通常涉及多个指标和方法。以下是一些常见的衡量网络质量的方法和指标：

1. 带宽（Bandwidth）：带宽是指网络传输数据的能力，通常以每秒传输的数据量（比特/秒）来衡量。更高的带宽通常表示更好的网络质量。
2. 延迟（Latency）：延迟是指数据从发送端到接收端所需的时间。低延迟表示数据传输速度快，网络响应更快。
3. 丢包率（Packet Loss Rate）：丢包率是指在数据传输过程中丢失的数据包的比例。较低的丢包率通常意味着网络质量较好。
4. 抖动（Jitter）：抖动是指数据包在传输过程中的变化或波动。较小的抖动表示网络稳定性较高。
5. 吞吐量（Throughput）：吞吐量是指网络传输的实际数据量，通常以单位时间内的数据传输量来衡量。更高的吞吐量表示网络质量更好。
6. 网络拓扑（Network Topology）：网络拓扑描述了网络中节点之间的连接方式和结构。合理的网络拓扑设计可以提高网络性能和质量。
7. 服务质量（Quality of Service，QoS）：QoS 是一组技术和机制，用于确保在网络中的数据传输中实现可接受的服务质量。QoS 可以通过各种方式实现，包括流量控制、优先级队列等。
8. 网络协议分析（Protocol Analysis）：通过分析网络协议和数据包，可以了解网络中的性能指标和问题，例如使用 Wireshark 等网络分析工具。

综合利用这些指标和方法，可以全面地评估网络质量，确定网络性能的优势和改进的空间。 但这些是运营商关注的指标, 对于普通用户, 只需要购买价格合适的路由器即可, 现代路由器都有自动调整网络质量的功能.

如何衡量网络体验

首先是可访问性, 能访问是最重要的基础. 因此, 域名解析服务需要满足基础的能力:

• 全面, 上级 DNS 服务需要权威, 且能够解析更多的域名
• 正确, 解析结果需要正确, 不能出现解析错误. 部分 DNS 服务商会对一些域名进行劫持或污染, 解析到广告页面.
• 及时, ip 地址变更后, 需要及时更新解析结果, 而不是返回旧的 ip 地址

其次是 DNS 解析结果的 IP 所能提供服务的网络质量.

互联网服务所能提供的网络质量, 通常强依赖地域, 服务器和客户端在地域上越接近, 则服务质量越好.

许多付费 DNS 解析服务商都支持按地域解析不同 IP, 例如这是阿里云能提供的一部分服务:

（1）运营商线路：支持按联通、电信、移动、教育网、鹏博士、广电网智能解析，细分到省份；
（2）海外地区线路：支持，细分到大洲、国家；
（3）阿里云线路：支持，细分到各个地区；
（4）自定义线路：支持自定义 IP 地址范围智能解析；

按区域解析不同 IP 的机制, 意味着不同地域的用户访问同一个域名时, 会得到不同的解析结果, 自然而然的, 优先解析到距离用户更近的服务器, 将会有更好的网络体验.

而优化用户网络体验这件事, 一般都是服务提供商根据用户的真实 IP 地址来做优化. 也就是对多数用户来说, 什么都不做, 即可以获得最好的网络体验.

自建 DNS 服务如何选择上游 DNS 服务

中文互联网你搜索到的所有资料都会推荐你选择权威 DNS 服务商, 例如阿里云, 腾讯云, Cloudflare, 谷歌等. 这些 DNS 可以满足网络服务的的可访问性, 因为它们全面/正确/及时, 但是, 它们未必会给你解析到最近的服务器 IP.

互联网上大量的资料推荐大企业的 DNS 服务有其历史原因.

曾经我国的 ISP 运营商, 仅靠 DNS 劫持加上 HTTP 的中间人攻击, 就能够实现对用户的流量劫持, 从而实现广告推送. 现如今随着 https 的普及, 这种劫持方式已较为少见, 但部分地区的小区宽带仍然可能存在这种问题. 针对 DNS 劫持问题, 实际上改 DNS IP 无济于事, 因为劫持可以针对 53 端口, 而绝大多数 DNS 请求都是未加密的.

此外, 一些特殊用户希望访问特殊网站, 而部分 DNS 服务商存在 IP 污染问题, 会将特殊网站的域名解析到错误的 IP 地址, 导致无法访问. 而权威 DNS 服务商则较少出现这样问题.

因此, 这里存在三个问题需要考虑:

1. IP 污染
2. DNS 劫持
3. 最优服务体验

权威 DNS 服务商可以解决问题 1 , 加密协议(DoT/DoH/QUIC)可以解决问题 2.

想要解决问题 3, 你需要使用回宽带运营商的默认 DNS 服务., 正如本文开头所说, 什么都不做, 即可以获得最好的网络体验.

但如果你是一个有追求的人, 或者特殊用户, 下文将介绍如何配置 AdguardHome 及 Clash 两种工具的配置, 以同时解决这三个问题.

权威且智能的 DNS 服务

AdguardHome 配置

AdguardHome, 以下简称ADG 是一个网络广告拦截与隐私保护软件, 也是一个 DNS 服务. 它支持自定义上游 DNS 服务, 以及自定义 DNS 规则.

ADG 默认的向上游请求 DNS 的方式是负载均衡, 用户可以设置多个上游, ADG将根据历史 DNS 查询加权权重选择其中 DNS 响应最快的上游. 简单说, ADG 会以更高的概率选择更快的 DNS 上游来解析域名, 以较低的概率选择非最优的 DNS 上游.

我们可以选择第三个选项: 最快的IP地址.

该选项带来的好处, ADG自行测试上游 DNS 的 IP 解析结果, 将其中延迟最低的 IP 返回给下游客户端. 以下是bilibili的常规解析结果.

你可以看到 IP 非常多, 如果ADG不测试 IP 解析结果, 而将所有 IP 返回给客户端, 那么客户端会做什么?

有的客户端会选择第一个 IP, 有的客户端会选择最后一个 IP, 有的客户端会随机选择一个 IP. 不管是哪种, 都未必是最优的选择.

开启最快的IP地址选项后, 以下是bilibili的优选解析结果, 这一步将会带来网络体验的提升.

最快的IP地址为什么不是默认选择? 这个功能这么实用, 为什么不默认开启?

因为它的代价是等待所有上游 DNS 的 IP 解析结果, 当你的上游同时有多个 DNS 服务商时, 向上游的查询时间以其中最慢的为准. 例如, 你的上游有平均服务时长50ms的阿里和平均服务时长500ms谷歌, ADG的上游查询时间将是500ms+.

因此用户在配置此选项时, 需要权衡上游 DNS 的服务质量和数量, 不要贪多.
这里我推荐设置两个上游, 一个权威(https://dns.alidns.com/dns-query), 加上一个运营商 DNS.

运营商的 DNS IP 各地都不相同, 可以点击这里查看自己所在地区的运营商 DNS.

或者, 你可以在路由器的管理界面上查看运营商推荐的 DNS :

Clash 配置

特殊需求用户看重 DNS 劫持和 IP 污染问题, 但又不想放弃最优服务体验, 可以使用Clash的dns模块.

其中nameserver-policy可以指定不同的域名使用不同的 DNS 服务商, 以下是一个示例配置:

dns:
  default-nameserver:
    - tls://223.5.5.5:853
    - tls://1.12.12.12:853
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://one.one.one.one/dns-query
    - https://dns.google/dns-query
  nameserver-policy:
    "geosite:cn,private,apple":
      - 202.103.24.68 # 自己所在地的运营商 DNS
      - https://dns.alidns.com/dns-query
    "geosite:geolocation-!cn":
      - https://one.one.one.one/dns-query
      - https://dns.google/dns-query

它的含义是:

• default-nameserver: 用于解析配置nameserver中的 DNS 服务的 IP
• nameserver: 用于解析网络请求的域名
• nameserver-policy: 根据策略, 指定不同的域名使用不同的 DNS 服务

感谢阅读

如果本文对您有所帮助, 还请点个赞. 也非常欢迎留言讨论.

ChatGPT VPN识别绕过方法

如何处理 ChatGPT 报错
“Unable to load site”
“Please try again later, if you are using a VPN, try turning it off.”
“Check the status page for information on outages.”

前言

chatgpt 目前仍然是使用体验最好的聊天机器人，但是在国内使用时，由于网络环境的限制，我们需要使用梯子来访问 chatgpt。但是 chatgpt 对梯子的检测较为严格，如果检测到使用了梯子，会直接拒绝访问。这里介绍一种绕过 chatgpt 对梯子检测的方法。

有其他人提到更换 IP 来绕过封锁, 但我们一般使用 IP 的地域已经是可以提供服务的地区, 所以这种方法并不一定是实际的拒绝服务原因.

另外有人提到梯子使用人数较多容易被识别, 劝人购买较贵的使用人数少的梯子, 这也很难成为合理理由, 在 ipv4 短缺的今天, 即便是海外, 也存在大量的社区使用 nat 分配端口, 共用一个 ipv4 的情况. chatgpt 一封就要封一大片, 作为一个被广泛使用的服务, 这样的检测设计肯定是不合理的.

对大众服务来说, 检测源 IP 一致性则更为合理. 付费梯子的特征通常是限制流量或限制网速, 因此多数使用梯子的用户选择按规则绕过. 绕过自己的运营商可直接访问的地址, 以减少流量消耗, 或者获得更快的访问速度, 仅在访问被防火墙拦截的地址时导入流量到代理. 这种访问目标服务的不同方式, 可能会造成源地址不一致. 例如访问 A 服务需要同时和域名 X 和域名 Y 进行通信, 而防火墙仅拦截了域名 X, 那么在 A 服务看到的同一请求的不同阶段的访问来源 IP 不一致.

解决代理策略导致的源 IP 不一致问题, 即可绕过 chatgpt 的梯子识别.

梯子规则中通常会含有域名规则, IP规则等.

我们还需要知道域名解析的 IP 结果是可以根据地域而变化的, 比如我在 A 地区时解析到附近的服务 IP, 在 B 地区时则解析到不同的 IP. 因此, DNS 的选择也非常重要.

DNS 选择

现在 DNS 有很多的协议, UDP:53 已经是非常落后而且极不安全的协议, 我国甚至已将 DNS 服务列入企业经营中的一级条目. 这主要来源于过去几十年我国的各级运行商使用DNS劫持加HTTP塞入了大量的跳转广告, 蒙骗不少网络小白, 招致大量投诉. 尽管现在Chrome/Edge已经标配自动跳转HTTPS, 标记HTTP网站为不安全, 但我国还存在许多的地方小区级的网络服务提供商, 以及国内各种老版本的Chromium封装魔改, 导致 DNS 劫持和 HTTP 劫持仍然存在.

因此, 我们需要选择一个安全的 DNS 服务协议, 以避免 DNS 劫持. 根据个人经验, 阿里云的223.5.5.5体验足够好. 当然, 当我提223.5.5.5时, 肯定不是UDP:53的 alidns, 而是DoH或DoT协议. 在配置时, 你需要使用tls://223.5.5.5, 或者https://dns.alidns.com/dns-query写入配置.

alidns 服务在绝大多数时候都不会污染, 仅在少数敏感时期会出现污染, 你也可以使用我自建的长期 dns 服务tls://dns.jqknono.com, 上游来自8.8.8.8和1.1.1.1, 通过缓存来加速访问.

域名规则

首先打开的检测网页会包含检测逻辑, 通过向不同域名发送请求来验证源 IP, 因此这里需要保持域名代理的一致性.

chatgpt 网页访问的域名除了自己的域名openai外, 还有auth0, cloudflare等第三方域名.

可以手动写入以下规则:

# openai
- DOMAIN-SUFFIX,chatgpt.com,PROXY
- DOMAIN-SUFFIX,openai.com,PROXY
- DOMAIN-SUFFIX,openai.org,PROXY
- DOMAIN-SUFFIX,auth0.com,PROXY
- DOMAIN-SUFFIX,cloudflare.com,PROXY

如何试验域名规则

上边列举的域名可能随着 ChatGPT 业务发展而有所变化, 下面说明域名的获取方法.

1. 浏览器打开 InPrivate 页面, 隐私页面可以避免缓存/cookies 等的影响
2. 按F12打开控制台, 选择Network/网络选项卡
3. 访问chat.openai.com, 或者chatgpt.com
4. 下图展示了这篇文章写成时 ChatGPT 使用的域名

仅添加这几个域名可能仍然不够, 这里分析访问失败的连接具体细节. 看到challenge的请求的Content-Security-Policy中含有众多域名, 我们将其一一添加到代理策略.

# openai
- DOMAIN-SUFFIX,chatgpt.com,PROXY
- DOMAIN-SUFFIX,openai.com,PROXY
- DOMAIN-SUFFIX,openai.org,PROXY
- DOMAIN-SUFFIX,auth0.com,PROXY
- DOMAIN-SUFFIX,cloudflare.com,PROXY
# additional
- DOMAIN-SUFFIX,oaistatic.com,PROXY
- DOMAIN-SUFFIX,oaiusercontent.com,PROXY
- DOMAIN-SUFFIX,intercomcdn.com,PROXY
- DOMAIN-SUFFIX,intercom.io,PROXY
- DOMAIN-SUFFIX,mixpanel.com,PROXY
- DOMAIN-SUFFIX,statsigapi.net,PROXY
- DOMAIN-SUFFIX,featuregates.org,PROXY
- DOMAIN-SUFFIX,stripe.com,PROXY
- DOMAIN-SUFFIX,browser-intake-datadoghq.com,PROXY
- DOMAIN-SUFFIX,sentry.io,PROXY
- DOMAIN-SUFFIX,live.net,PROXY
- DOMAIN-SUFFIX,live.com,PROXY
- DOMAIN-SUFFIX,windows.net,PROXY
- DOMAIN-SUFFIX,onedrive.com,PROXY
- DOMAIN-SUFFIX,microsoft.com,PROXY
- DOMAIN-SUFFIX,azure.com,PROXY
- DOMAIN-SUFFIX,sharepoint.com,PROXY
- DOMAIN-SUFFIX,gstatic.com,PROXY
- DOMAIN-SUFFIX,google.com,PROXY
- DOMAIN-SUFFIX,googleapis.com,PROXY
- DOMAIN-SUFFIX,googleusercontent.com,PROXY

IP 规则

如果上述步骤尝试后仍然不能访问chatgpt.com, 则可能还存在基于IP的检测行为, 以下是我在连接跟踪中尝试出的一些 IP, 你可以自行尝试使用, 需要说明这些 IP 并不一定适用于每个地区, 你或许需要自行尝试.

# openai
- IP-CIDR6,2606:4700:4400::6812:231c/96,PROXY
- IP-CIDR,17.253.84.253/24,PROXY
- IP-CIDR,172.64.152.228/24,PROXY
- IP-CIDR,104.18.35.28/16,PROXY

如何试验 IP 规则

你需要了解自己的梯子客户端工具, 在连接跟踪显示页面, 观察新增的连接, 通过这些连接的 IP 地址来尝试添加规则.

以下是简单的步骤描述:

1. 浏览器打开 InPrivate 页面, 隐私页面可以避免缓存/cookies 等的影响
2. 访问chat.openai.com, 或者chatgpt.com
3. 梯子客户端中观察新增连接, 将这些连接加入到代理规则

协议规则

QUIC是基于UDP的加密协议, chatgpt 大量使用了 QUIC 流量, 因此梯子的服务端/客户端需要支持 UDP 代理, 有许多梯子是不支持 UDP 的, 这也是导致 chatgpt 无法访问的原因之一. 客户端和服务端都支持 UDP, 还需要用户明确配置, 一些客户端会配置默认不代理 UDP 流量. 如果对 UDP 设置不熟悉, 可以设置屏蔽代理客户端的 QUIC 流量, 或者在浏览器设置屏蔽 QUIC. 浏览器发现 QUIC 不通会自动切换到基于 TCP 的 HTTP/2. QUIC 是基于 UDP 的加密协议, 多数时候可以获得更流畅的体验, 有兴趣的可以自行尝试.

最简单配置–白名单模式

配置仅中国 IP 直连, 未匹配到的流量走代理, 这样可以保证 chatgpt 的访问, 也可以保证其他国外服务的访问.

这种方式的缺点就是流量消耗大, 网络流畅度体验依赖梯子的网络质量, 如果您对自己的梯子有信心, 可以尝试这种方式.

当然, 您还得记得开启UDP代理.

杂谈

• _index

第三方库的陷阱

• 第三方库的陷阱

今天聊到最近出的第三方日志库的一个漏洞, 可以很低门槛的利用以执行远程命令. 一个日志库和远程命令看着毫不相干, 但是画蛇添足的第三方库遍地都是.

读的代码越多越感受到很多开源代码的水平非常差, 无论它有多少 k 的 star, star 代表了需求, 不代表开发水平.

开源的好处是有更多的人来开发, 好处是特性迅速增加, bug 有人来解, 代码有人来审核, 但是水平参差不齐.

如果没有一个强有力的提交约束, 代码的质量很难保证.

代码越多增加的攻击面越多

虽说重复造轮子不好, 但是产品需求就是婴儿车轮子, 一个塑料轮子怎么都用不坏, 装了个飞机轮胎, 徒增攻击面和维护成本. 因此如果只需要婴儿车的轮子, 不需要大材小用.

维护成本高, 第三方库需要专门的流程和人员去维护. 华为一个魔改的测试框架, 直接导致升级编译器就用例失败, 升级测试框架和升级编译器产生冲突, 维护时要花大量时间继续魔改这条路. 作为参与者深刻体会到魔改三方库的困难. 如果魔改的是特性可以合回开源库还好说, 为了自己的需求去侵入式的定制开发, 会导致很难维护.

对待第三方库华为创建了一系列流程, 可以说阻力重重.

门槛收的极紧, 增加的第三方库需要 18 级专家和 20 级部长评审, 基本只有久负盛名的三方库能被使用.

所有第三方库都放在 thirdparty 文件夹下, 全量编译时 CI 和源库对比, 严格禁止侵入式修改.

专门的工具追踪所有第三方库的版本, 这部分请了外包人员来管理, 如果开发申请升级版本需要提申请, 部长审核.

很难找部长去处理这样的事, 当一个流程非常繁琐的时候, 它实际上是在劝你不要这样做.

对待第三方库应该保持不轻信的态度, 相信自己人的开发.

方案设计模板

• 方案设计模板

XXX系统/子系统详细设计

修改记录

技术评审意见

设计背景

名词解释

• SIP: 会话初始协议 (Session Initiation Protocol)
• RTP: 实时传输协议（Real-time Transport Protocol）

设计目标

功能需求

非功能需求（不可省略）

系统环境

相关软件及硬件（可选）

系统限制

数据规模估计（不可省略）

遍历已有

设计思路及折衷

假设及与其它系统的依赖/联系

系统设计

基本介绍

系统架构图及说明

系统流程图及说明（可选）

与外部系统的接口

全局性数据结构说明

XXX1模块简要说明

XXX1模块的功能

与其它模块的接口

XXX2模块简要说明

XXX2模块的功能

与其它模块的接口

威胁建模

升级影响（不可省略）

风险评估及对其它系统影响（可选）

已知的或可预知的风险

与其它系统/模块可能的影响

创新点挖掘（可选）

附件及参考资料

命令行语法约定

• 命令行语法约定

参考

• https://www.ibm.com/docs/en/iotdm/11.3?topic=interface-command-line-syntax
• https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/command-line-syntax-key
• https://developers.google.com/style/code-syntax
• https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_01
• https://ftpdocs.broadcom.com/cadocs/0/CA%20ARCserve%20%20Backup%20r16-CHS/Bookshelf_Files/HTML/cmndline/cl_cmd_line_syntax_char.htm

e.g.

命令行手册中括号的含义

• 命令行手册中括号的含义

命令行手册中括号的含义

在命令行帮助中，不同种类的括号通常有以下含义：

1. 尖括号 <>：
   • 尖括号用于表示必需参数，即在运行命令时必须提供的值。通常用于表示命令的基本语法和参数。
   • 例如：command <filename> 表示你需要提供一个文件名作为必需参数，如 command file.txt。
2. 方括号 []：
   • 方括号用于表示可选参数，即在运行命令时可以选择是否提供的值。它们通常用于标记命令的可选参数和选项。
   • 例如：command [option] 表示你可以选择性地提供一个选项，如 command -v 或 command。
3. 大括号 {}：
   • 大括号通常用于表示一组选项或值，表示你需要从中选择一个。它们也被称为"选择性参数组"。
   • 例如：command {option1 | option2 | option3} 表示你必须从给定的选项中选择一个，如 command option2。
4. 圆括号 ()：
   • 圆括号在命令行帮助中通常用于表示参数的分组，以明确参数的结构和优先级。
   • 例如：command (option1 | option2) filename 表示你需要选择 option1 或 option2，并提供一个文件名作为参数，如 command option1 file.txt。

这些括号的使用旨在帮助用户理解命令的语法和参数选择，从而正确地使用命令行工具。在阅读命令行帮助时，仔细注意括号的含义和作用是很重要的，这样可以避免错误的命令输入并获得所需的结果。

华为C++编程规范

• 华为C++编程规范

C++语言编程规范

目的

规则并不是完美的，通过禁止在特定情况下有用的特性，可能会对代码实现造成影响。但是我们制定规则的目的“为了大多数程序员可以得到更多的好处”， 如果在团队运作中认为某个规则无法遵循，希望可以共同改进该规则。 参考该规范之前，希望您具有相应的C++语言基础能力，而不是通过该文档来学习C++语言。

1. 了解C++语言的ISO标准；
2. 熟知C++语言的基本语言特性，包括C++ 03/11/14/17相关特性；
3. 了解C++语言的标准库；

总体原则

代码需要在保证功能正确的前提下，满足可读、可维护、安全、可靠、可测试、高效、可移植的特征要求。

重点关注

1. 约定C++语言的编程风格，比如命名，排版等。
2. C++语言的模块化设计，如何设计头文件，类，接口和函数。
3. C++语言相关特性的优秀实践，比如常量，类型转换，资源管理，模板等。
4. 现代C++语言的优秀实践，包括C++11/14/17中可以提高代码可维护性，提高代码可靠性的相关约定。
5. 本规范优先适于用C++17版本。

约定

规则：编程时必须遵守的约定(must)

建议：编程时应该遵守的约定(should)

本规范适用通用C++标准, 如果没有特定的标准版本，适用所有的版本(C++03/11/14/17)。

例外

无论是’规则’还是’建议’，都必须理解该条目这么规定的原因，并努力遵守。 但是，有些规则和建议可能会有例外。

在不违背总体原则，经过充分考虑，有充足的理由的前提下，可以适当违背规范中约定。 例外破坏了代码的一致性，请尽量避免。‘规则’的例外应该是极少的。

下列情况，应风格一致性原则优先： 修改外部开源代码、第三方代码时，应该遵守开源代码、第三方代码已有规范，保持风格统一。

2 命名

通用命名

驼峰风格(CamelCase) 大小写字母混用，单词连在一起，不同单词间通过单词首字母大写来分开。 按连接后的首字母是否大写，又分: 大驼峰(UpperCamelCase)和小驼峰(lowerCamelCase)

注意： 上表中__常量__是指全局作用域、namespace域、类的静态成员域下，以 const或constexpr 修饰的基本数据类型、枚举、字符串类型的变量，不包括数组和其他类型变量。 上表中__变量__是指除常量定义以外的其他变量，均使用小驼峰风格。

文件命名

规则2.2.1 C++文件以.cpp结尾，头文件以.h结尾

我们推荐使用.h作为头文件的后缀，这样头文件可以直接兼容C和C++。 我们推荐使用.cpp作为实现文件的后缀，这样可以直接区分C++代码，而不是C代码。

目前业界还有一些其他的后缀的表示方法：

• 头文件： .hh, .hpp, .hxx
• cpp文件：.cc, .cxx, .c

如果当前项目组使用了某种特定的后缀，那么可以继续使用，但是请保持风格统一。 但是对于本文档，我们默认使用.h和.cpp作为后缀。

规则2.2.2 C++文件名和类名保持一致

C++的头文件和cpp文件名和类名保持一致，使用下划线小写风格。

如果有一个类叫DatabaseConnection，那么对应的文件名：

• database_connection.h
• database_connection.cpp

结构体，命名空间，枚举等定义的文件名类似。

函数命名

函数命名统一使用大驼峰风格，一般采用动词或者动宾结构。

class List {
public:
	void AddElement(const Element& element);
	Element GetElement(const unsigned int index) const;
	bool IsEmpty() const;
};

namespace Utils {
    void DeleteUser();
}

类型命名

类型命名采用大驼峰命名风格。 所有类型命名——类、结构体、联合体、类型定义（typedef）、枚举——使用相同约定，例如：

// classes, structs and unions
class UrlTable { ...
class UrlTableTester { ...
struct UrlTableProperties { ...
union Packet { ...

// typedefs
typedef std::map<std::string, UrlTableProperties*> PropertiesMap;

// enums
enum UrlTableErrors { ...

对于命名空间的命名，建议使用大驼峰：

// namespace
namespace OsUtils {
 
namespace FileUtils {
     
}
 
}

建议2.4.1 避免滥用 typedef或者#define 对基本类型起别名

除有明确的必要性，否则不要用 typedef/#define 对基本数据类型进行重定义。 优先使用<cstdint>头文件中的基本类型：

变量命名

通用变量命名采用小驼峰，包括全局变量，函数形参，局部变量，成员变量。

std::string tableName;  // Good: 推荐此风格
std::string tablename;  // Bad: 禁止此风格
std::string path;       // Good: 只有一个单词时，小驼峰为全小写

规则2.5.1 全局变量应增加 ‘g_’ 前缀，静态变量命名不需要加特殊前缀

全局变量是应当尽量少使用的，使用时应特别注意，所以加上前缀用于视觉上的突出，促使开发人员对这些变量的使用更加小心。

• 全局静态变量命名与全局变量相同。
• 函数内的静态变量命名与普通局部变量相同。
• 类的静态成员变量和普通成员变量相同。

int g_activeConnectCount;

void Func()
{
    static int packetCount = 0; 
    ...
}

规则2.5.2 类的成员变量命名以小驼峰加后下划线组成

class Foo {
private:
    std::string fileName_;   // 添加_后缀，类似于K&R命名风格
};

对于struct/union的成员变量，仍采用小驼峰不加后缀的命名方式，与局部变量命名风格一致。

宏、常量、枚举命名

宏、枚举值采用全大写，下划线连接的格式。 全局作用域内，有名和匿名namespace内的 const 常量，类的静态成员常量，全大写，下划线连接；函数局部 const 常量和类的普通const成员变量，使用小驼峰命名风格。

#define MAX(a, b)   (((a) < (b)) ? (b) : (a)) // 仅对宏命名举例，并不推荐用宏实现此类功能

enum TintColor {    // 注意，枚举类型名用大驼峰，其下面的取值是全大写，下划线相连
    RED,
    DARK_RED,
    GREEN,
    LIGHT_GREEN
};

int Func(...)
{
    const unsigned int bufferSize = 100;    // 函数局部常量
    char *p = new char[bufferSize];
    ...
}

namespace Utils {
	const unsigned int DEFAULT_FILE_SIZE_KB = 200;        // 全局常量
}

3 格式

行宽

规则3.1.1 行宽不超过 120 个字符

建议每行字符数不要超过 120 个。如果超过120个字符，请选择合理的方式进行换行。

例外:

• 如果一行注释包含了超过120 个字符的命令或URL，则可以保持一行，以方便复制、粘贴和通过grep查找；
• 包含长路径的 #include 语句可以超出120 个字符，但是也需要尽量避免；
• 编译预处理中的error信息可以超出一行。 预处理的 error 信息在一行便于阅读和理解，即使超过 120 个字符。

#ifndef XXX_YYY_ZZZ
#error Header aaaa/bbbb/cccc/abc.h must only be included after xxxx/yyyy/zzzz/xyz.h, because xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
#endif

缩进

规则3.2.1 使用空格进行缩进，每次缩进4个空格

只允许使用空格(space)进行缩进，每次缩进为 4 个空格。不允许使用Tab符进行缩进。 当前几乎所有的集成开发环境（IDE）都支持配置将Tab符自动扩展为4空格输入；请配置你的IDE支持使用空格进行缩进。

大括号

规则3.3.1 使用 K&R 缩进风格

K&R风格 换行时，函数（不包括lambda表达式）左大括号另起一行放行首，并独占一行；其他左大括号跟随语句放行末。 右大括号独占一行，除非后面跟着同一语句的剩余部分，如 do 语句中的 while，或者 if 语句的 else/else if，或者逗号、分号。

如：

struct MyType {     // 跟随语句放行末，前置1空格
    ...
};

int Foo(int a)
{                   // 函数左大括号独占一行，放行首
    if (...) {
        ...
    } else {
        ...
    }
}

推荐这种风格的理由：

• 代码更紧凑；
• 相比另起一行，放行末使代码阅读节奏感上更连续；
• 符合后来语言的习惯，符合业界主流习惯；
• 现代集成开发环境（IDE）都具有代码缩进对齐显示的辅助功能，大括号放在行尾并不会对缩进和范围产生理解上的影响。

对于空函数体，可以将大括号放在同一行：

class MyClass {
public:
    MyClass() : value_(0) {}
   
private:
    int value_;
};

函数声明和定义

规则3.4.1 函数声明和定义的返回类型和函数名在同一行；函数参数列表超出行宽时要换行并合理对齐

在声明和定义函数的时候，函数的返回值类型应该和函数名在同一行；如果行宽度允许，函数参数也应该放在一行；否则，函数参数应该换行，并进行合理对齐。 参数列表的左圆括号总是和函数名在同一行，不要单独一行；右圆括号总是跟随最后一个参数。

换行举例：

ReturnType FunctionName(ArgType paramName1, ArgType paramName2)   // Good：全在同一行
{
    ...
}

ReturnType VeryVeryVeryLongFunctionName(ArgType paramName1,     // 行宽不满足所有参数，进行换行
                                        ArgType paramName2,     // Good：和上一行参数对齐
                                        ArgType paramName3)
{
    ...
}

ReturnType LongFunctionName(ArgType paramName1, ArgType paramName2, // 行宽限制，进行换行
    ArgType paramName3, ArgType paramName4, ArgType paramName5)     // Good: 换行后 4 空格缩进
{
    ...
}

ReturnType ReallyReallyReallyReallyLongFunctionName(            // 行宽不满足第1个参数，直接换行
    ArgType paramName1, ArgType paramName2, ArgType paramName3) // Good: 换行后 4 空格缩进
{
    ...
}

函数调用

规则3.5.1 函数调用入参列表应放在一行，超出行宽换行时，保持参数进行合理对齐

函数调用时，函数参数列表放在一行。参数列表如果超过行宽，需要换行并进行合理的参数对齐。 左圆括号总是跟函数名，右圆括号总是跟最后一个参数。

换行举例：

ReturnType result = FunctionName(paramName1, paramName2);   // Good：函数参数放在一行

ReturnType result = FunctionName(paramName1,
                                 paramName2,                // Good：保持与上方参数对齐
                                 paramName3);

ReturnType result = FunctionName(paramName1, paramName2,
    paramName3, paramName4, paramName5);                    // Good：参数换行，4 空格缩进

ReturnType result = VeryVeryVeryLongFunctionName(           // 行宽不满足第1个参数，直接换行
    paramName1, paramName2, paramName3);                    // 换行后，4 空格缩进

如果函数调用的参数存在内在关联性，按照可理解性优先于格式排版要求，对参数进行合理分组换行。

// Good：每行的参数代表一组相关性较强的数据结构，放在一行便于理解
int result = DealWithStructureLikeParams(left.x, left.y,     // 表示一组相关参数
                                         right.x, right.y);  // 表示另外一组相关参数

if语句

规则3.6.1 if语句必须要使用大括号

我们要求if语句都需要使用大括号，即便只有一条语句。

理由：

• 代码逻辑直观，易读；
• 在已有条件语句代码上增加新代码时不容易出错；
• 对于在if语句中使用函数式宏时，有大括号保护不易出错（如果宏定义时遗漏了大括号）。

if (objectIsNotExist) {         // Good：单行条件语句也加大括号
    return CreateNewObject();
}

规则3.6.2 禁止 if/else/else if 写在同一行

条件语句中，若有多个分支，应该写在不同行。

如下是正确的写法：

if (someConditions) {
    DoSomething();
    ...
} else {  // Good: else 与 if 在不同行
    ...
}

下面是不符合规范的案例：

if (someConditions) { ... } else { ... } // Bad: else 与 if 在同一行

循环语句

规则3.7.1 循环语句必须使用大括号

和条件表达式类似，我们要求for/while循环语句必须加上大括号，即便循环体是空的，或循环语句只有一条。

for (int i = 0; i < someRange; i++) {   // Good: 使用了大括号
    DoSomething();
}

while (condition) { }   // Good：循环体是空，使用大括号

while (condition) {
    continue;           // Good：continue 表示空逻辑，使用大括号
}

坏的例子：

for (int i = 0; i < someRange; i++)
    DoSomething();      // Bad: 应该加上括号

while (condition);      // Bad：使用分号容易让人误解是while语句中的一部分

switch语句

规则3.8.1 switch 语句的 case/default 要缩进一层

switch 语句的缩进风格如下：

switch (var) {
    case 0:             // Good: 缩进
        DoSomething1(); // Good: 缩进
        break;
    case 1: {           // Good: 带大括号格式
        DoSomething2();
        break;
    }
    default:
        break;
}

switch (var) {
case 0:                 // Bad: case 未缩进
    DoSomething();
    break;
default:                // Bad: default 未缩进
    break;
}

表达式

建议3.9.1 表达式换行要保持换行的一致性，运算符放行末

较长的表达式，不满足行宽要求的时候，需要在适当的地方换行。一般在较低优先级运算符或连接符后面截断，运算符或连接符放在行末。 运算符、连接符放在行末，表示“未结束，后续还有”。 例：

// 假设下面第一行已经不满足行宽要求

if ((currentValue > threshold) &&  // Good：换行后，逻辑操作符放在行尾
    someCondition) {
    DoSomething();
    ...
}

int result = reallyReallyLongVariableName1 +    // Good
             reallyReallyLongVariableName2;

表达式换行后，注意保持合理对齐，或者4空格缩进。参考下面例子

int sum = longVariableName1 + longVariableName2 + longVariableName3 +
    longVariableName4 + longVariableName5 + longVariableName6;         // Good: 4空格缩进

int sum = longVariableName1 + longVariableName2 + longVariableName3 +
          longVariableName4 + longVariableName5 + longVariableName6;   // Good: 保持对齐

变量赋值

规则3.10.1 多个变量定义和赋值语句不允许写在一行

每行只有一个变量初始化的语句，更容易阅读和理解。

int maxCount = 10;
bool isCompleted = false;

下面是不符合规范的示例：

int maxCount = 10; bool isCompleted = false; // Bad：多个变量初始化需要分开放在多行，每行一个变量初始化
int x, y = 0;  // Bad：多个变量定义需要分行，每行一个

int pointX;
int pointY;
...
pointX = 1; pointY = 2;  // Bad：多个变量赋值语句放同一行

例外：for 循环头、if 初始化语句（C++17）、结构化绑定语句（C++17）中可以声明和初始化多个变量。这些语句中的多个变量声明有较强关联，如果强行分成多行会带来作用域不一致，声明和初始化割裂等问题。

初始化

初始化包括结构体、联合体、及数组的初始化

规则3.11.1 初始化换行时要有缩进，并进行合理对齐

结构体或数组初始化时，如果换行应保持4空格缩进。 从可读性角度出发，选择换行点和对齐位置。

const int rank[] = {
    16, 16, 16, 16, 32, 32, 32, 32,
    64, 64, 64, 64, 32, 32, 32, 32
};

指针与引用

建议3.12.1 指针类型"*“跟随变量名或者类型，不要两边都留有或者都没有空格

指针命名: *靠左靠右都可以，但是不要两边都有或者都没有空格。

int* p = nullptr;  // Good
int *p = nullptr;  // Good

int*p = nullptr;   // Bad
int * p = nullptr; // Bad

例外：当变量被 const 修饰时，"*” 无法跟随变量，此时也不要跟随类型。

const char * const VERSION = "V100";

建议3.12.2 引用类型"&“跟随变量名或者类型，不要两边都留有或者都没有空格

引用命名：&靠左靠右都可以，但是不要两边都有或者都没有空格。

int i = 8;

int& p = i;     // Good
int &p = i;     // Good
int*& rp = pi;  // Good，指针的引用，*& 一起跟随类型
int *&rp = pi;  // Good，指针的引用，*& 一起跟随变量名
int* &rp = pi;  // Good，指针的引用，* 跟随类型，& 跟随变量名

int & p = i;    // Bad
int&p = i;      // Bad

编译预处理

规则3.13.1 编译预处理的”#“统一放在行首，嵌套编译预处理语句时，”#“可以进行缩进

编译预处理的”#“统一放在行首，即使编译预处理的代码是嵌入在函数体中的，”#“也应该放在行首。

规则3.13.2 避免使用宏

宏会忽略作用域，类型系统以及各种规则，容易引发问题。应尽量避免使用宏定义，如果必须使用宏，要保证证宏名的唯一性。 在C++中，有许多方式来避免使用宏：

• 用const或enum定义易于理解的常量
• 用namespace避免名字冲突
• 用inline函数避免函数调用的开销
• 用template函数来处理多种类型

在文件头保护宏、条件编译、日志记录等必要场景中可以使用宏。

规则3.13.3 禁止使用宏来表示常量

宏是简单的文本替换，在预处理阶段完成，运行报错时直接报相应的值；跟踪调试时也是显示值，而不是宏名； 宏没有类型检查，不安全； 宏没有作用域。

规则3.13.4 禁止使用函数式宏

宏义函数式宏前，应考虑能否用函数替代。对于可替代场景，建议用函数替代宏。 函数式宏的缺点如下：

• 函数式宏缺乏类型检查，不如函数调用检查严格
• 宏展开时宏参数不求值，可能会产生非预期结果
• 宏没有独立的作用域
• 宏的技巧性太强，例如#的用法和无处不在的括号，影响可读性
• 在特定场景中必须用编译器对宏的扩展语法，如GCC的statement expression，影响可移植性
• 宏在预编译阶段展开后，在期后编译、链接和调试时都不可见；而且包含多行的宏会展开为一行。函数式宏难以调试、难以打断点，不利于定位问题
• 对于包含大量语句的宏，在每个调用点都要展开。如果调用点很多，会造成代码空间的膨胀

函数没有宏的上述缺点。但是，函数相比宏，最大的劣势是执行效率不高（增加函数调用的开销和编译器优化的难度）。 为此，可以在必要时使用内联函数。内联函数跟宏类似，也是在调用点展开。不同之处在于内联函数是在编译时展开。

内联函数兼具函数和宏的优点：

• 内联函数执行严格的类型检查
• 内联函数的参数求值只会进行一次
• 内联函数就地展开，没有函数调用的开销
• 内联函数比函数优化得更好

对于性能要求高的产品代码，可以考虑用内联函数代替函数。

例外： 在日志记录场景中，需要通过函数式宏保持调用点的文件名（FILE）、行号（LINE）等信息。

空格和空行

规则3.14.1 水平空格应该突出关键字和重要信息，避免不必要的留白

水平空格应该突出关键字和重要信息，每行代码尾部不要加空格。总体规则如下：

• if, switch, case, do, while, for等关键字之后加空格；
• 小括号内部的两侧，不要加空格；
• 大括号内部两侧有无空格，左右必须保持一致；
• 一元操作符（& * + ‐ ~ !）之后不要加空格；
• 二元操作符（= + ‐ < > * / % | & ^ <= >= == != ）左右两侧加空格
• 三目运算符（? :）符号两侧均需要空格
• 前置和后置的自增、自减（++ –）和变量之间不加空格
• 结构体成员操作符（. ->）前后不加空格
• 逗号(,)前面不加空格，后面增加空格
• 对于模板和类型转换(<>)和类型之间不要添加空格
• 域操作符(::)前后不要添加空格
• 冒号(:)前后根据情况来判断是否要添加空格

常规情况：

void Foo(int b) {  // Good：大括号前应该留空格

int i = 0;  // Good：变量初始化时，=前后应该有空格，分号前面不要留空格

int buf[BUF_SIZE] = {0};    // Good：大括号内两侧都无空格

函数定义和函数调用：

int result = Foo(arg1,arg2);
                    ^    // Bad: 逗号后面需要增加空格

int result = Foo( arg1, arg2 );
                 ^          ^  // Bad: 函数参数列表的左括号后面不应该有空格，右括号前面不应该有空格

指针和取地址

x = *p;     // Good：*操作符和指针p之间不加空格
p = &x;     // Good：&操作符和变量x之间不加空格
x = r.y;    // Good：通过.访问成员变量时不加空格
x = r->y;   // Good：通过->访问成员变量时不加空格

操作符：

x = 0;   // Good：赋值操作的=前后都要加空格
x = -5;  // Good：负数的符号和数值之前不要加空格
++x;     // Good：前置和后置的++/--和变量之间不要加空格
x--;

if (x && !y)  // Good：布尔操作符前后要加上空格，！操作和变量之间不要空格
v = w * x + y / z;  // Good：二元操作符前后要加空格
v = w * (x + z);    // Good：括号内的表达式前后不需要加空格

int a = (x < y) ? x : y;  // Good: 三目运算符， ？和：前后需要添加空格

循环和条件语句：

if (condition) {  // Good：if关键字和括号之间加空格，括号内条件语句前后不加空格
    ...
} else {           // Good：else关键字和大括号之间加空格
    ...
}

while (condition) {}   // Good：while关键字和括号之间加空格，括号内条件语句前后不加空格

for (int i = 0; i < someRange; ++i) {  // Good：for关键字和括号之间加空格，分号之后加空格
    ...
}

switch (condition) {  // Good: switch 关键字后面有1空格
    case 0:     // Good：case语句条件和冒号之间不加空格
        ...
        break;
    ...
    default:
        ...
        break;
}

模板和转换

// 尖括号(< and >) 不与空格紧邻, < 前没有空格, > 和 ( 之间也没有.
vector<string> x;
y = static_cast<char*>(x);

// 在类型与指针操作符之间留空格也可以, 但要保持一致.
vector<char *> x;

域操作符

std::cout;    // Good: 命名空间访问，不要留空格

int MyClass::GetValue() const {}  // Good: 对于成员函数定义，不要留空格

冒号

// 添加空格的场景

// Good: 类的派生需要留有空格
class Sub : public Base {
   
};

// 构造函数初始化列表需要留有空格
MyClass::MyClass(int var) : someVar_(var)
{
    DoSomething();
}

// 位域表示也留有空格
struct XX {
    char a : 4;    
    char b : 5;    
    char c : 4;
};

// 不添加空格的场景

// Good: 对于public:, private:这种类访问权限的冒号不用添加空格
class MyClass {
public:
    MyClass(int var);
private:
    int someVar_;
};

// 对于switch-case的case和default后面的冒号不用添加空格
switch (value)
{
    case 1:
        DoSomething();
        break;
    default:
        break;
}

注意：当前的集成开发环境（IDE）可以设置删除行尾的空格，请正确配置。

建议3.14.1 合理安排空行，保持代码紧凑

减少不必要的空行，可以显示更多的代码，方便代码阅读。下面有一些建议遵守的规则：

• 根据上下内容的相关程度，合理安排空行；
• 函数内部、类型定义内部、宏内部、初始化表达式内部，不使用连续空行
• 不使用连续 3 个空行，或更多
• 大括号内的代码块行首之前和行尾之后不要加空行，但namespace的大括号内不作要求。

int Foo()
{
    ...
}



int Bar()  // Bad：最多使用连续2个空行。
{
    ...
}


if (...) {
        // Bad：大括号内的代码块行首不要加入空行
    ...
        // Bad：大括号内的代码块行尾不要加入空行
}

int Foo(...)
{
        // Bad：函数体内行首不要加空行
    ...
}

类

规则3.15.1 类访问控制块的声明依次序是 public:, protected:, private:，缩进和 class 关键字对齐

class MyClass : public BaseClass {
public:      // 注意没有缩进
    MyClass();  // 标准的4空格缩进
    explicit MyClass(int var);
    ~MyClass() {}

    void SomeFunction();
    void SomeFunctionThatDoesNothing()
    {
    }

    void SetVar(int var) { someVar_ = var; }
    int GetVar() const { return someVar_; }

private:
    bool SomeInternalFunction();

    int someVar_;
    int someOtherVar_;
};

在各个部分中，建议将类似的声明放在一起, 并且建议以如下的顺序: 类型 (包括 typedef, using 和嵌套的结构体与类), 常量, 工厂函数, 构造函数, 赋值运算符, 析构函数, 其它成员函数, 数据成员。

规则3.15.2 构造函数初始化列表放在同一行或按四格缩进并排多行

// 如果所有变量能放在同一行:
MyClass::MyClass(int var) : someVar_(var)
{
    DoSomething();
}

// 如果不能放在同一行,
// 必须置于冒号后, 并缩进4个空格
MyClass::MyClass(int var)
    : someVar_(var), someOtherVar_(var + 1)  // Good: 逗号后面留有空格
{
    DoSomething();
}

// 如果初始化列表需要置于多行, 需要逐行对齐
MyClass::MyClass(int var)
    : someVar_(var),             // 缩进4个空格
      someOtherVar_(var + 1)
{ 
    DoSomething();
}

4 注释

一般的，尽量通过清晰的架构逻辑，好的符号命名来提高代码可读性；需要的时候，才辅以注释说明。 注释是为了帮助阅读者快速读懂代码，所以要从读者的角度出发，按需注释。

注释内容要简洁、明了、无二义性，信息全面且不冗余。

注释跟代码一样重要。 写注释时要换位思考，用注释去表达此时读者真正需要的信息。在代码的功能、意图层次上进行注释，即注释解释代码难以表达的意图，不要重复代码信息。 修改代码时，也要保证其相关注释的一致性。只改代码，不改注释是一种不文明行为，破坏了代码与注释的一致性，让阅读者迷惑、费解，甚至误解。

使用英文进行注释。

注释风格

在 C++ 代码中，使用 /* */和 // 都是可以的。 按注释的目的和位置，注释可分为不同的类型，如文件头注释、函数头注释、代码注释等等； 同一类型的注释应该保持统一的风格。

注意：本文示例代码中，大量使用 ‘//’ 后置注释只是为了更精确的描述问题，并不代表这种注释风格更好。

文件头注释

规则3.1 文件头注释必须包含版权许可

/*

• Copyright (c) 2020 XXX
• Licensed under the Apache License, Version 2.0 (the “License”);
• you may not use this file except in compliance with the License.
• You may obtain a copy of the License at *

• http://www.apache.org/licenses/LICENSE-2.0
  

*

• Unless required by applicable law or agreed to in writing, software
• distributed under the License is distributed on an “AS IS” BASIS,
• WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
• See the License for the specific language governing permissions and
• limitations under the License. */

函数头注释

规则4.3.1 公有（public）函数必须编写函数头注释

公有函数属于类对外提供的接口，调用者需要了解函数的功能、参数的取值范围、返回的结果、注意事项等信息才能正常使用。 特别是参数的取值范围、返回的结果、注意事项等都无法做到自注示，需要编写函数头注释辅助说明。

规则4.3.2 禁止空有格式的函数头注释

并不是所有的函数都需要函数头注释； 函数签名无法表达的信息，加函数头注释辅助说明;

函数头注释统一放在函数声明或定义上方，使用如下风格之一： 使用//写函数头

// 单行函数头
int Func1(void);

// 多行函数头
// 第二行
int Func2(void);

使用/* */写函数头

/* 单行函数头 */
int Func1(void);

/*
 * 另一种单行函数头
 */
int Func2(void);

/*
 * 多行函数头
 * 第二行
 */
int Func3(void);

函数尽量通过函数名自注释，按需写函数头注释。 不要写无用、信息冗余的函数头；不要写空有格式的函数头。

函数头注释内容可选，但不限于：功能说明、返回值，性能约束、用法、内存约定、算法实现、可重入的要求等等。 模块对外头文件中的函数接口声明，其函数头注释，应当将重要、有用的信息表达清楚。

例：

/*
 * 返回实际写入的字节数，-1表示写入失败
 * 注意，内存 buf 由调用者负责释放
 */
int WriteString(const char *buf, int len);

坏的例子：

/*
 * 函数名：WriteString
 * 功能：写入字符串
 * 参数：
 * 返回值：
 */
int WriteString(const char *buf, int len);

上面例子中的问题：

• 参数、返回值，空有格式没内容
• 函数名信息冗余
• 关键的 buf 由谁释放没有说清楚

代码注释

规则4.4.1 代码注释放于对应代码的上方或右边

规则4.4.2 注释符与注释内容间要有1空格；右置注释与前面代码至少1空格

代码上方的注释，应该保持对应代码一样的缩进。 选择并统一使用如下风格之一： 使用//

// 这是单行注释
DoSomething();

// 这是多行注释
// 第二行
DoSomething();

使用/*' '*/

/* 这是单行注释 */
DoSomething();

/*
 * 另一种方式的多行注释
 * 第二行
 */
DoSomething();

代码右边的注释，与代码之间，至少留1空格，建议不超过4空格。 通常使用扩展后的 TAB 键即可实现 1-4 空格的缩进。

选择并统一使用如下风格之一：

int foo = 100;  // 放右边的注释
int bar = 200;  /* 放右边的注释 */

右置格式在适当的时候，上下对齐会更美观。 对齐后的注释，离左边代码最近的那一行，保证1-4空格的间隔。 例：

const int A_CONST = 100;         /* 相关的同类注释，可以考虑上下对齐 */
const int ANOTHER_CONST = 200;   /* 上下对齐时，与左侧代码保持间隔 */

当右置的注释超过行宽时，请考虑将注释置于代码上方。

规则4.4.3 不用的代码段直接删除，不要注释掉

被注释掉的代码，无法被正常维护；当企图恢复使用这段代码时，极有可能引入易被忽略的缺陷。 正确的做法是，不需要的代码直接删除掉。若再需要时，考虑移植或重写这段代码。

这里说的注释掉代码，包括用 /* */ 和 //，还包括 #if 0， #ifdef NEVER_DEFINED 等等。

5 头文件

头文件职责

头文件是模块或文件的对外接口，头文件的设计体现了大部分的系统设计。 头文件中适合放置接口的声明，不适合放置实现（内联函数除外）。对于cpp文件中内部才需要使用的函数、宏、枚举、结构定义等不要放在头文件中。 头文件应当职责单一。头文件过于复杂，依赖过于复杂还是导致编译时间过长的主要原因。

建议5.1.1 每一个.cpp文件应有一个对应的.h文件，用于声明需要对外公开的类与接口

通常情况下，每个.cpp文件都有一个相应的.h，用于放置对外提供的函数声明、宏定义、类型定义等。 如果一个.cpp文件不需要对外公布任何接口，则其就不应当存在。 例外：程序的入口（如main函数所在的文件），单元测试代码，动态库代码。

示例:

// Foo.h

#ifndef FOO_H
#define FOO_H

class Foo {
public:
    Foo();
    void Fun();
   
private:
    int value_;
};

#endif

// Foo.cpp
#include "Foo.h"

namespace { // Good: 对内函数的声明放在.cpp文件的头部，并声明为匿名namespace或者static限制其作用域
    void Bar()
    {
    }
}

...

void Foo::Fun()
{
    Bar();
}

头文件依赖

规则5.2.1 禁止头文件循环依赖

头文件循环依赖，指 a.h 包含 b.h，b.h 包含 c.h，c.h 包含 a.h， 导致任何一个头文件修改，都导致所有包含了a.h/b.h/c.h的代码全部重新编译一遍。 而如果是单向依赖，如a.h包含b.h，b.h包含c.h，而c.h不包含任何头文件，则修改a.h不会导致包含了b.h/c.h的源代码重新编译。

头文件循环依赖直接体现了架构设计上的不合理，可通过优化架构去避免。

规则5.2.2 头文件必须编写#define保护，防止重复包含

为防止头文件被重复包含，所有头文件都应当使用 #define 保护；不要使用 #pragma once

定义包含保护符时，应该遵守如下规则： 1）保护符使用唯一名称； 2）不要在受保护部分的前后放置代码或者注释，文件头注释除外。

示例：假定timer模块的timer.h，其目录为timer/include/timer.h,应按如下方式保护：

#ifndef TIMER_INCLUDE_TIMER_H
#define TIMER_INCLUDE_TIMER_H
...
#endif

规则5.2.3 禁止通过声明的方式引用外部函数接口、变量

只能通过包含头文件的方式使用其他模块或文件提供的接口。 通过 extern 声明的方式使用外部函数接口、变量，容易在外部接口改变时可能导致声明和定义不一致。 同时这种隐式依赖，容易导致架构腐化。

不符合规范的案例：

// a.cpp内容

extern int Fun();   // Bad: 通过extern的方式使用外部函数

void Bar()
{
    int i = Fun();
    ...
}

// b.cpp内容

int Fun()
{
    // Do something
}

应该改为：

// a.cpp内容

#include "b.h"   // Good: 通过包含头文件的方式使用其他.cpp提供的接口

void Bar()
{
    int i = Fun();
    ...
}

// b.h内容

int Fun();

// b.cpp内容

int Fun()
{
    // Do something
}

例外，有些场景需要引用其内部函数，但并不想侵入代码时，可以 extern 声明方式引用。 如： 针对某一内部函数进行单元测试时，可以通过 extern 声明来引用被测函数； 当需要对某一函数进行打桩、打补丁处理时，允许 extern 声明该函数。

规则5.2.4 禁止在extern “C"中包含头文件

在 extern “C” 中包含头文件，有可能会导致 extern “C” 嵌套，部分编译器对 extern “C” 嵌套层次有限制，嵌套层次太多会编译错误。

在C，C++混合编程的情况下，在extern “C"中包含头文件，可能会导致被包含头文件的原有意图遭到破坏，比如链接规范被不正确地更改。

示例，存在a.h和b.h两个头文件：

// a.h内容

...
#ifdef __cplusplus
void Foo(int);
#define A(value) Foo(value)
#else
void A(int)
#endif

// b.h内容

...
#ifdef __cplusplus
extern "C" {
#endif

#include "a.h"
void B();

#ifdef __cplusplus
}
#endif

使用C++预处理器展开b.h，将会得到

extern "C" {
    void Foo(int);
    void B();
}

按照 a.h 作者的本意，函数 Foo 是一个 C++ 自由函数，其链接规范为 “C++"。 但在 b.h 中，由于 #include "a.h" 被放到了 extern "C" 的内部，函数 Foo 的链接规范被不正确地更改了。

例外： 如果在 C++ 编译环境中，想引用纯C的头文件，这些C头文件并没有 extern "C" 修饰。非侵入式的做法是，在 extern "C" 中去包含C头文件。

建议5.2.1尽量避免使用前置声明，而是通过#include来包含头文件

前置声明（forward declaration）通常指类、模板的纯粹声明，没伴随着其定义。

• 优点：
  1. 前置声明能够节省编译时间，多余的 #include 会迫使编译器展开更多的文件，处理更多的输入。
  2. 前置声明能够节省不必要的重新编译的时间。 #include 使代码因为头文件中无关的改动而被重新编译多次。
• 缺点：
  1. 前置声明隐藏了依赖关系，头文件改动时，用户的代码会跳过必要的重新编译过程。
  2. 前置声明可能会被库的后续更改所破坏。前置声明模板有时会妨碍头文件开发者变动其 API. 例如扩大形参类型，加个自带默认参数的模板形参等等。
  3. 前置声明来自命名空间 std:: 的 symbol 时，其行为未定义（在C++11标准规范中明确说明）。
  4. 前置声明了不少来自头文件的 symbol 时，就会比单单一行的 include 冗长。
  5. 仅仅为了能前置声明而重构代码（比如用指针成员代替对象成员）会使代码变得更慢更复杂。
  6. 很难判断什么时候该用前置声明，什么时候该用#include，某些场景下面前置声明和#include互换以后会导致意想不到的结果。

所以我们尽可能避免使用前置声明，而是使用#include头文件来保证依赖关系。

6 作用域

命名空间

建议6.1.1 对于cpp文件中不需要导出的变量，常量或者函数，请使用匿名namespace封装或者用static修饰

在C++ 2003标准规范中，使用static修饰文件作用域的变量，函数等被标记为deprecated特性，所以更推荐使用匿名namespace。

主要原因如下：

1. static在C++中已经赋予了太多的含义，静态函数成员变量，静态成员函数，静态全局变量，静态函数局部变量，每一种都有特殊的处理。
2. static只能保证变量，常量和函数的文件作用域，但是namespace还可以封装类型等。
3. 统一namespace来处理C++的作用域，而不需要同时使用static和namespace来管理。
4. static修饰的函数不能用来实例化模板，而匿名namespace可以。

但是不要在 .h 中使用中使用匿名namespace或者static。

// Foo.cpp

namespace {
    const int MAX_COUNT = 20;
    void InternalFun() {};
}

void Foo::Fun()
{
    int i = MAX_COUNT;
   
    InternalFun();
}

规则6.1.1 不要在头文件中或者#include之前使用using导入命名空间

说明：使用using导入命名空间会影响后续代码，易造成符号冲突，所以不要在头文件以及源文件中的#include之前使用using导入命名空间。 示例：

// 头文件a.h
namespace NamespaceA {
    int Fun(int);
}

// 头文件b.h
namespace NamespaceB {
    int Fun(int);
}

using namespace NamespaceB;

void G()
{
    Fun(1);
}

// 源代码a.cpp
#include "a.h"
using namespace NamespaceA;
#include "b.h"

void main()
{
    G(); // using namespace NamespaceA在#include “b.h”之前，引发歧义：NamespaceA::Fun，NamespaceB::Fun调用不明确
}

对于在头文件中使用using导入单个符号或定义别名，允许在模块自定义名字空间中使用，但禁止在全局名字空间中使用。

// foo.h

#include <fancy/string>
using fancy::string;  // Bad，禁止向全局名字空间导入符号

namespace Foo {
    using fancy::string;  // Good，可以在模块自定义名字空间中导入符号
    using MyVector = fancy::vector<int>;  // Good，C++11可在自定义名字空间中定义别名
}

全局函数和静态成员函数

建议6.2.1 优先使用命名空间来管理全局函数，如果和某个class有直接关系的，可以使用静态成员函数

说明：非成员函数放在名字空间内可避免污染全局作用域， 也不要用类+静态成员方法来简单管理全局函数。 如果某个全局函数和某个类有紧密联系， 那么可以作为类的静态成员函数。

如果你需要定义一些全局函数，给某个cpp文件使用，那么请使用匿名namespace来管理。

namespace MyNamespace {
    int Add(int a, int b);
}

class File {
public:
    static File CreateTempFile(const std::string& fileName);
};

全局常量和静态成员常量

建议6.3.1 优先使用命名空间来管理全局常量，如果和某个class有直接关系的，可以使用静态成员常量

说明：全局常量放在命名空间内可避免污染全局作用域， 也不要用类+静态成员常量来简单管理全局常量。 如果某个全局常量和某个类有紧密联系， 那么可以作为类的静态成员常量。

如果你需要定义一些全局常量，只给某个cpp文件使用，那么请使用匿名namespace来管理。

namespace MyNamespace {
    const int MAX_SIZE = 100;
}

class File {
public:
    static const std::string SEPARATOR;
};

全局变量

建议6.4.1 尽量避免使用全局变量，考虑使用单例模式

说明：全局变量是可以修改和读取的，那么这样会导致业务代码和这个全局变量产生数据耦合。

int g_counter = 0;

// a.cpp
g_counter++;

// b.cpp
g_counter++;

// c.cpp
cout << g_counter << endl;

使用单实例模式

class Counter {
public:
    static Counter& GetInstance()
    {
        static Counter counter;
        return counter;
    }  // 单实例实现简单举例
   
    void Increase()
    {
        value_++;
    }
   
    void Print() const
    {
        std::cout << value_ << std::endl;
    }

private:
    Counter() : value_(0) {}

private:
    int value_;
};

// a.cpp
Counter::GetInstance().Increase();

// b.cpp
Counter::GetInstance().Increase();

// c.cpp
Counter::GetInstance().Print();

实现单例模式以后，实现了全局唯一一个实例，和全局变量同样的效果，并且单实例提供了更好的封装性。

例外：有的时候全局变量的作用域仅仅是模块内部，这样进程空间里面就会有多个全局变量实例，每个模块持有一份，这种场景下是无法使用单例模式解决的。

7 类

构造，拷贝构造，赋值和析构函数

构造，拷贝，移动和析构函数提供了对象的生命周期管理方法：

• 构造函数（constructor）： X()
• 拷贝构造函数（copy constructor）：X(const X&)
• 拷贝赋值操作符（copy assignment）：operator=(const X&)
• 移动构造函数（move constructor）：X(X&&) C++11以后提供
• 移动赋值操作符（move assignment）：operator=(X&&) C++11以后提供
• 析构函数（destructor）：~X()

规则7.1.1 类的成员变量必须显式初始化

说明：如果类有成员变量，没有定义构造函数，又没有定义默认构造函数，编译器将自动生成一个构造函数，但编译器生成的构造函数并不会对成员变量进行初始化，对象状态处于一种不确定性。

例外：

• 如果类的成员变量具有默认构造函数，那么可以不需要显式初始化。

示例：如下代码没有构造函数，私有数据成员无法初始化：

class Message {
public:
    void ProcessOutMsg()
    {
        //…
    }

private:
    unsigned int msgID_;
    unsigned int msgLength_;
    unsigned char* msgBuffer_;
    std::string someIdentifier_;
};

Message message;   // message成员变量没有初始化
message.ProcessOutMsg();   // 后续使用存在隐患

// 因此，有必要定义默认构造函数，如下：
class Message {
public:
    Message() : msgID_(0), msgLength_(0), msgBuffer_(nullptr)
    {
    }

    void ProcessOutMsg()
    {
        // …
    }

private:
    unsigned int msgID_;
    unsigned int msgLength_;
    unsigned char* msgBuffer_;
    std::string someIdentifier_; // 具有默认构造函数，不需要显式初始化
};

建议7.1.1 成员变量优先使用声明时初始化（C++11）和构造函数初始化列表初始化

说明：C++11的声明时初始化可以一目了然的看出成员初始值，应当优先使用。如果成员初始化值和构造函数相关，或者不支持C++11，则应当优先使用构造函数初始化列表来初始化成员。相比起在构造函数体中对成员赋值，初始化列表的代码更简洁，执行性能更好，而且可以对const成员和引用成员初始化。

class Message {
public:
    Message() : msgLength_(0)  // Good，优先使用初始化列表
    {
        msgBuffer_ = nullptr;  // Bad，不推荐在构造函数中赋值
    }
   
private:
    unsigned int msgID_{0};  // Good，C++11中使用
    unsigned int msgLength_;
    unsigned char* msgBuffer_;
};

规则7.1.2 为避免隐式转换，将单参数构造函数声明为explicit

说明：单参数构造函数如果没有用explicit声明，则会成为隐式转换函数。 示例：

class Foo {
public:
    explicit Foo(const string& name): name_(name)
    {
    }
private:
    string name_;
};


void ProcessFoo(const Foo& foo){}

int main(void)
{
    std::string test = "test";
    ProcessFoo(test);  // 编译不通过
    return 0;
}

上面的代码编译不通过，因为ProcessFoo需要的参数是Foo类型，传入的string类型不匹配。

如果将Foo构造函数的explicit关键字移除，那么调用ProcessFoo传入的string就会触发隐式转换，生成一个临时的Foo对象。往往这种隐式转换是让人迷惑的，并且容易隐藏Bug，得到了一个不期望的类型转换。所以对于单参数的构造函数是要求explicit声明。

规则7.1.3 如果不需要拷贝构造函数、赋值操作符 / 移动构造函数、赋值操作符，请明确禁止

说明：如果用户不定义，编译器默认会生成拷贝构造函数和拷贝赋值操作符， 移动构造和移动赋值操作符（移动语义的函数C++11以后才有）。 如果我们不要使用拷贝构造函数，或者赋值操作符，请明确拒绝：

1. 将拷贝构造函数或者赋值操作符设置为private，并且不实现：

class Foo {
private:
    Foo(const Foo&);
    Foo& operator=(const Foo&);
};

2. 使用C++11提供的delete, 请参见后面现代C++的相关章节。

3. 推荐继承NoCopyable、NoMovable，禁止使用DISALLOW_COPY_AND_MOVE，DISALLOW_COPY，DISALLOW_MOVE等宏。

class Foo : public NoCopyable, public NoMovable {
};

NoCopyable和NoMovable的实现：

class NoCopyable {
public:
    NoCopyable() = default;
    NoCopyable(const NoCopyable&) = delete;
    NoCopyable& operator = (NoCopyable&) = delete;
};

class NoMovable {
public:
    NoMovable() = default;
    NoMovable(NoMovable&&) noexcept = delete;
    NoMovable& operator = (NoMovable&&) noexcept = delete;
};

规则7.1.4 拷贝构造和拷贝赋值操作符应该是成对出现或者禁止

拷贝构造函数和拷贝赋值操作符都是具有拷贝语义的，应该同时出现或者禁止。

// 同时出现
class Foo {
public:
    ...
    Foo(const Foo&);
    Foo& operator=(const Foo&);
    ...
};

// 同时default， C++11支持
class Foo {
public:
    Foo(const Foo&) = default;
    Foo& operator=(const Foo&) = default;
};

// 同时禁止, C++11可以使用delete
class Foo {
private:
    Foo(const Foo&);
    Foo& operator=(const Foo&);
};

规则7.1.5 移动构造和移动赋值操作符应该是成对出现或者禁止

在C++11中增加了move操作，如果需要某个类支持移动操作，那么需要实现移动构造和移动赋值操作符。

移动构造函数和移动赋值操作符都是具有移动语义的，应该同时出现或者禁止。

// 同时出现
class Foo {
public:
    ...
    Foo(Foo&&);
    Foo& operator=(Foo&&);
    ...
};

// 同时default， C++11支持
class Foo {
public:
    Foo(Foo&&) = default;
    Foo& operator=(Foo&&) = default;
};

// 同时禁止, 使用C++11的delete
class Foo {
public:
    Foo(Foo&&) = delete;
    Foo& operator=(Foo&&) = delete;
};

规则7.1.6 禁止在构造函数和析构函数中调用虚函数

说明：在构造函数和析构函数中调用当前对象的虚函数，会导致未实现多态的行为。 在C++中，一个基类一次只构造一个完整的对象。

示例：类Base是基类，Sub是派生类

class Base {                      
public:               
    Base();
    virtual void Log() = 0;    // 不同的派生类调用不同的日志文件
};

Base::Base()         // 基类构造函数
{
    Log();           // 调用虚函数Log
}                                                 

class Sub : public Base {      
public:
    virtual void Log();         
};

当执行如下语句： Sub sub; 会先执行Sub的构造函数，但首先调用Base的构造函数，由于Base的构造函数调用虚函数Log，此时Log还是基类的版本，只有基类构造完成后，才会完成派生类的构造，从而导致未实现多态的行为。 同样的道理也适用于析构函数。

规则7.1.7 多态基类中的拷贝构造函数、拷贝赋值操作符、移动构造函数、移动赋值操作符必须为非public函数或者为delete函数

如果报一个派生类对象直接赋值给基类对象，会发生切片，只拷贝或者移动了基类部分，损害了多态行为。 【反例】 如下代码中，基类没有定义拷贝构造函数或拷贝赋值操作符，编译器会自动生成这两个特殊成员函数， 如果派生类对象赋值给基类对象时就发生切片。可以将此例中的拷贝构造函数和拷贝赋值操作符声明为delete，编译器可检查出此类赋值行为。

class Base {                      
public:               
    Base() = default;
    virtual ~Base() = default;
    ...
    virtual void Fun() { std::cout << "Base" << std::endl;}
};

class Derived : public Base {
    ...
    void Fun() override { std::cout << "Derived" << std::endl; }
};

void Foo(const Base &base)
{
    Base other = base; // 不符合：发生切片
    other.Fun(); // 调用的时Base类的Fun函数
}

Derived d;
Foo(d); // 传入的是派生类对象

1. 将拷贝构造函数或者赋值操作符设置为private，并且不实现：

继承

规则7.2.1 基类的析构函数应该声明为virtual，不准备被继承的类需要声明为final

说明：只有基类析构函数是virtual，通过多态调用的时候才能保证派生类的析构函数被调用。

示例：基类的析构函数没有声明为virtual导致了内存泄漏。

class Base {
public:
    virtual std::string getVersion() = 0;
   
    ~Base()
    {
        std::cout << "~Base" << std::endl;
    }
};

class Sub : public Base {
public:
    Sub() : numbers_(nullptr)
    { 
    }
   
    ~Sub()
    {
        delete[] numbers_;
        std::cout << "~Sub" << std::endl;
    }
   
    int Init()
    {
        const size_t numberCount = 100;
        numbers_ = new (std::nothrow) int[numberCount];
        if (numbers_ == nullptr) {
            return -1;
        }
       
        ...
    }

    std::string getVersion()
    {
        return std::string("hello!");
    }
private:
    int* numbers_;
};

int main(int argc, char* args[])
{
    Base* b = new Sub();

    delete b;
    return 0;
}

由于基类Base的析构函数没有声明为virtual，当对象被销毁时，只会调用基类的析构函数，不会调用派生类Sub的析构函数，导致内存泄漏。 例外： NoCopyable、NoMovable这种没有任何行为，仅仅用来做标识符的类，可以不定义虚析构也不定义final。

规则7.2.2 禁止虚函数使用缺省参数值

说明：在C++中，虚函数是动态绑定的，但函数的缺省参数却是在编译时就静态绑定的。这意味着你最终执行的函数是一个定义在派生类，但使用了基类中的缺省参数值的虚函数。为了避免虚函数重载时，因参数声明不一致给使用者带来的困惑和由此导致的问题，规定所有虚函数均不允许声明缺省参数值。 示例：虚函数display缺省参数值text是由编译时刻决定的，而非运行时刻，没有达到多态的目的：

class Base {
public:
    virtual void Display(const std::string& text = "Base!")
    {
        std::cout << text << std::endl;
    }
   
    virtual ~Base(){}
};

class Sub : public Base {
public:
    virtual void Display(const std::string& text  = "Sub!")
    {
        std::cout << text << std::endl;
    }
   
    virtual ~Sub(){}
};

int main()
{
    Base* base = new Sub();
    Sub* sub = new Sub();
  
    ...
   
    base->Display();  // 程序输出结果: Base! 而期望输出：Sub!
    sub->Display();   // 程序输出结果: Sub!
   
    delete base;
    delete sub;
    return 0;
};

规则7.2.3 禁止重新定义继承而来的非虚函数

说明：因为非虚函数无法实现动态绑定，只有虚函数才能实现动态绑定：只要操作基类的指针，即可获得正确的结果。

示例：

class Base {
public:
    void Fun();
};

class Sub : public Base {
public:
    void Fun();
};

Sub* sub = new Sub();                    
Base* base = sub;

sub->Fun();    // 调用子类的Fun                 
base->Fun();   // 调用父类的Fun
//...

多重继承

在实际开发过程中使用多重继承的场景是比较少的，因为多重继承使用过程中有下面的典型问题：

1. 菱形继承所带来的数据重复，以及名字二义性。因此，C++引入了virtual继承来解决这类问题;
2. 即便不是菱形继承，多个父类之间的名字也可能存在冲突，从而导致的二义性;
3. 如果子类需要扩展或改写多个父类的方法时，造成子类的职责不明，语义混乱;
4. 相对于委托，继承是一种白盒复用，即子类可以访问父类的protected成员, 这会导致更强的耦合。而多重继承，由于耦合了多个父类，相对于单根继承，这会产生更强的耦合关系。

多重继承具有下面的优点： 多重继承提供了一种更简单的组合来实现多种接口或者类的组装与复用。

所以，对于多重继承的只有下面几种情况下面才允许使用多重继承。

建议7.3.1 使用多重继承来实现接口分离与多角色组合

如果某个类需要实现多重接口，可以通过多重继承把多个分离的接口组合起来，类似 scala 语言的 traits 混入。

class Role1 {};
class Role2 {};
class Role3 {};

class Object1 : public Role1, public Role2 {
    // ...
};

class Object2 : public Role2, public Role3 {
    // ...
};

在C++标准库中也有类似的实现样例：

class basic_istream {};
class basic_ostream {};

class basic_iostream : public basic_istream, public basic_ostream {
 
};

重载

重载操作符要有充分理由,而且不要改变操作符原有语义，例如不要使用 ‘+’ 操作符来做减运算。 操作符重载令代码更加直观，但也有一些不足：

• 混淆直觉，误以为该操作和内建类型一样是高性能的，忽略了性能降低的可能；
• 问题定位时不够直观，按函数名查找比按操作符显然更方便。
• 重载操作符如果行为定义不直观(例如将‘+’ 操作符来做减运算)，会让代码产生混淆。
• 赋值操作符的重载引入的隐式转换会隐藏很深的bug。可以定义类似Equals()、CopyFrom()等函数来替代=,==操作符。

8 函数

函数设计

规则8.1.1 避免函数过长，函数不超过50行（非空非注释）

函数应该可以一屏显示完 (50行以内)，只做一件事情，而且把它做好。

过长的函数往往意味着函数功能不单一，过于复杂，或过分呈现细节，未进行进一步抽象。

例外：某些实现算法的函数，由于算法的聚合性与功能的全面性，可能会超过50行。

即使一个长函数现在工作的非常好, 一旦有人对其修改, 有可能出现新的问题, 甚至导致难以发现的bug。 建议将其拆分为更加简短并易于管理的若干函数，以便于他人阅读和修改代码。

内联函数

建议8.2.1 内联函数不超过10行（非空非注释）

说明：内联函数具有一般函数的特性，它与一般函数不同之处只在于函数调用的处理。一般函数进行调用时，要将程序执行权转到被调用函数中，然后再返回到调用它的函数中；而内联函数在调用时，是将调用表达式用内联函数体来替换。

内联函数只适合于只有 1~10 行的小函数。对一个含有许多语句的大函数，函数调用和返回的开销相对来说微不足道，也没有必要用内联函数实现，一般的编译器会放弃内联方式，而采用普通的方式调用函数。

如果内联函数包含复杂的控制结构，如循环、分支(switch)、try-catch 等语句，一般编译器将该函数视同普通函数。 虚函数、递归函数不能被用来做内联函数。

函数参数

建议8.3.1 函数参数使用引用取代指针

说明：引用比指针更安全，因为它一定非空，且一定不会再指向其他目标；引用不需要检查非法的NULL指针。

如果是基于老平台开发的产品，则优先顺从原有平台的处理方式。 选择 const 避免参数被修改，让代码阅读者清晰地知道该参数不被修改，可大大增强代码可读性。

例外：当传入参数为编译期长度未知的数组时，可以使用指针而不是引用。

建议8.3.2 使用强类型参数，避免使用void*

尽管不同的语言对待强类型和弱类型有自己的观点，但是一般认为c/c++是强类型语言，既然我们使用的语言是强类型的，就应该保持这样的风格。 好处是尽量让编译器在编译阶段就检查出类型不匹配的问题。

使用强类型便于编译器帮我们发现错误，如下代码中注意函数 FooListAddNode 的使用：

struct FooNode {
    struct List link;
    int foo;
};

struct BarNode {
    struct List link;
    int bar;
}

void FooListAddNode(void *node) // Bad: 这里用 void * 类型传递参数
{
    FooNode *foo = (FooNode *)node;
    ListAppend(&g_FooList, &foo->link);
}

void MakeTheList()
{
    FooNode *foo = nullptr;
    BarNode *bar = nullptr;
    ...

    FooListAddNode(bar);        // Wrong: 这里本意是想传递参数 foo，但错传了 bar，却没有报错
}

1. 可以使用模板函数来实现参数类型的变化。
2. 可以使用基类指针来实现多态。

建议8.3.3 函数的参数个数不超过5个

函数的参数过多，会使得该函数易于受外部变化的影响，从而影响维护工作。函数的参数过多同时也会增大测试的工作量。

如果超过可以考虑:

• 看能否拆分函数
• 看能否将相关参数合在一起，定义结构体

9 C++其他特性

常量与初始化

不变的值更易于理解、跟踪和分析，所以应该尽可能地使用常量代替变量，定义值的时候，应该把const作为默认的选项。

规则9.1.1 不允许使用宏来表示常量

说明：宏是简单的文本替换，在预处理阶段时完成，运行报错时直接报相应的值；跟踪调试时也是显示值，而不是宏名；宏没有类型检查，不安全；宏没有作用域。

#define MAX_MSISDN_LEN 20    // 不好

// C++请使用const常量
const int MAX_MSISDN_LEN = 20; // 好

// 对于C++11以上版本，可以使用constexpr
constexpr int MAX_MSISDN_LEN = 20;

建议9.1.1 一组相关的整型常量应定义为枚举

说明：枚举比#define或const int更安全。编译器会检查参数值是否位于枚举取值范围内，避免错误发生。

// 好的例子：
enum Week {
    SUNDAY,
    MONDAY,
    TUESDAY,
    WEDNESDAY,
    THURSDAY,
    FRIDAY,
    SATURDAY
};

enum Color {
    RED,
    BLACK,
    BLUE
};

void ColorizeCalendar(Week today, Color color);

ColorizeCalendar(BLUE, SUNDAY); // 编译报错，参数类型错误

// 不好的例子:
const int SUNDAY = 0;
const int MONDAY = 1;

const int BLACK  = 0;
const int BLUE   = 1;

bool ColorizeCalendar(int today, int color);
ColorizeCalendar(BLUE, SUNDAY); // 不会报错