说明：操作系统默认 240 秒后，才会关闭处于 time_wait 状态的连接，在高并发访问下，服务器端会因为处于 time_wait 的连接数太多，可能无法建立新的连接，所以需要在服务器上调小此等待值。

正例：在 linux 服务器上请通过变更/etc/sysctl.conf 文件去修改该缺省值（秒）：

net.ipv4.tcp_fin_timeout = 30

2.【推荐】调大服务器所支持的最大文件句柄数（File Descriptor，简写为 fd）。

说明：主流操作系统的设计是将 TCP/UDP 连接采用与文件一样的方式去管理，即一个连接对应于一个 fd。主流的 linux 服务器默认所支持最大 fd 数量为 1024，当并发连接数很大时很

容易因为 fd 不足而出现“open too many files”错误，导致新的连接无法建立。 建议将 linux

服务器所支持的最大句柄数调高数倍（与服务器的内存数量相关）。

3.【推荐】给 JVM 环境参数设置-XX:+HeapDumpOnOutOfMemoryError 参数，让 JVM 碰到 OOM 场景时输出 dump 信息。

说明：OOM 的发生是有概率的，甚至相隔数月才出现一例，出错时的堆内信息对解决问题非常有帮助。

4.【推荐】在线上生产环境，JVM 的 Xms 和 Xmx 设置一样大小的内存容量，避免在 GC 后调整堆大小带来的压力。

5.【参考】服务器内部重定向使用 forward；外部重定向地址使用 URL 拼装工具类来生成，否则会带来 URL 维护不一致的问题和潜在的安全风险。

1）GroupID 格式：com.{公司/BU }.业务线 [.子业务线]，最多 4 级。

说明：{公司/BU} 例如：alibaba/taobao/tmall/aliexpress 等 BU 一级；子业务线可选。正例：com.taobao.jstorm 或 com.alibaba.dubbo.register

2）ArtifactID 格式：产品线名-模块名。语义不重复不遗漏，先到中央仓库去查证一下。正例：dubbo-client / fastjson-api / jstorm-tool

3）Version：详细规定参考下方。

2.【强制】二方库版本号命名方式：主版本号.次版本号.修订号

1）主版本号：产品方向改变，或者大规模 API 不兼容，或者架构不兼容升级。

2）次版本号：保持相对兼容性，增加主要功能特性，影响范围极小的 API 不兼容修改。

3）修订号：保持完全兼容性，修复 BUG、新增次要功能特性等。

说明：注意起始版本号必须为：1.0.0，而不是 0.0.1 正式发布的类库必须先去中央仓库进行查证，使版本号有延续性，正式版本号不允许覆盖升级。如当前版本：1.3.3，那么下一个合理的版本号：1.3.4 或 1.4.0 或 2.0.0

3.【强制】线上应用不要依赖 SNAPSHOT 版本（安全包除外）。

说明：不依赖 SNAPSHOT 版本是保证应用发布的幂等性。另外，也可以加快编译时的打包构建。

4.【强制】二方库的新增或升级，保持除功能点之外的其它 jar 包仲裁结果不变。如果有改变， 必须明确评估和验证，建议进行 dependency:resolve 前后信息比对，如果仲裁结果完全不一致，那么通过 dependency:tree 命令，找出差异点，进行<excludes>排除 jar 包。

5.【强制】二方库里可以定义枚举类型，参数可以使用枚举类型，但是接口返回值不允许使用枚举类型或者包含枚举类型的 POJO 对象。

6.【强制】依赖于一个二方库群时，必须定义一个统一的版本变量，避免版本号不一致。

说明：依赖 springframework-core,-context,-beans，它们都是同一个版本，可以定义一个变量来保存版本：${spring.version}，定义依赖的时候，引用该版本。

7.【强制】禁止在子项目的 pom 依赖中出现相同的 GroupId，相同的 ArtifactId，但是不同的Version。

说明：在本地调试时会使用各子项目指定的版本号，但是合并成一个 war，只能有一个版本号出现在最后的 lib 目录中。可能出现线下调试是正确的，发布到线上却出故障的问题。

8.【推荐】所有 pom 文件中的依赖声明放在<dependencies>语句块中，所有版本仲裁放在

<dependencyManagement>语句块中。

说明：<dependencyManagement>里只是声明版本，并不实现引入，因此子项目需要显式的声明依赖，version 和 scope 都读取自父 pom。而<dependencies>所有声明在主 pom 的

<dependencies>里的依赖都会自动引入，并默认被所有的子项目继承。

9.【推荐】二方库不要有配置项，最低限度不要再增加配置项。

10.【参考】为避免应用二方库的依赖冲突问题，二方库发布者应当遵循以下原则：

1）精简可控原则。移除一切不必要的 API 和依赖，只包含 Service API、必要的领域模型对象、Utils 类、常量、枚举等。如果依赖其它二方库，尽量是 provided 引入，让二方库使用者去依赖具体版本号；无 log 具体实现，只依赖日志框架。

2）稳定可追溯原则。每个版本的变化应该被记录，二方库由谁维护，源码在哪里，都需要能方便查到。除非用户主动升级版本，否则公共二方库的行为不应该发生变化。

Web 层，也可以直接依赖于 Service 层，依此类推：

开放接口层：可直接封装 Service 方法暴露成 RPC 接口；通过 Web 封装成 http 接口；进行网关安全控制、流量控制等。

终端显示层：各个端的模板渲染并执行显示的层。当前主要是 velocity 渲染，JS 渲染，

JSP 渲染，移动端展示等。

Web 层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。

Service 层：相对具体的业务逻辑服务层。

Manager 层：通用业务处理层，它有如下特征：

1）对第三方平台封装的层，预处理返回结果及转化异常信息；

2）对 Service 层通用能力的下沉，如缓存方案、中间件通用处理；

3）与 DAO 层交互，对多个 DAO 的组合复用。

DAO 层：数据访问层，与底层 MySQL、Oracle、Hbase 等进行数据交互。

外部接口或第三方平台：包括其它部门 RPC 开放接口，基础平台，其它公司的 HTTP 接口。

2.【参考】 （分层异常处理规约）在 DAO 层，产生的异常类型有很多，无法用细粒度的异常进行 catch，使用 catch(Exception e)方式，并 throw new DAOException(e)，不需要打印日志，因为日志在 Manager/Service 层一定需要捕获并打印到日志文件中去，如果同台服务器再打日志，浪费性能和存储。在 Service 层出现异常时，必须记录出错日志到磁盘，尽可能带上参数信息，相当于保护案发现场。如果 Manager 层与 Service 同机部署，日志方式与 DAO 层处理一致，如果是单独部署，则采用与 Service 一致的处理方式。Web 层绝不应该继续往上抛异常，因为已经处于顶层，如果意识到这个异常将导致页面无法正常渲染，那么就应该直接

跳转到友好错误页面，加上用户容易理解的错误提示信息。开放接口层要将异常处理成错误码和错误信息方式返回。

3.【参考】分层领域模型规约：

DO（Data Object）：此对象与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。

DTO（Data Transfer Object）：数据传输对象，Service 或 Manager 向外传输的对象。

BO（Business Object）：业务对象，由 Service 层输出的封装业务逻辑的对象。

AO（Application Object）：应用对象，在 Web 层与 Service 层之间抽象的复用对象模型， 极为贴近展示层，复用度不高。

VO（View Object）：显示层对象，通常是 Web 向模板渲染引擎层传输的对象。

Query：数据查询对象，各层接收上层的查询请求。注意超过 2 个参数的查询封装，禁止使用 Map 类来传输。

2.【强制】POJO 类的布尔属性不能加 is，而数据库字段必须加 is_，要求在 resultMap 中进行字段与属性之间的映射。

说明：参见定义 POJO 类以及数据库字段定义规定，在<resultMap>中增加映射，是必须的。在 MyBatis Generator 生成的代码中，需要进行对应的修改。

3.【强制】不要用 resultClass 当返回参数，即使所有类属性名与数据库字段一一对应，也需要定义；反过来，每一个表也必然有一个 POJO 类与之对应。

说明：配置映射关系，使字段与 DO 类解耦，方便维护。

4.【强制】sql.xml 配置参数使用：#{}，#param# 不要使用${} 此种方式容易出现 SQL 注入。

5.【强制】iBATIS 自带的 queryForList(String statementName,int start,int size)不推荐使用。

说明：其实现方式是在数据库取到statementName 对应的SQL 语句的所有记录，再通过subList

取 start,size 的子集合。

正例：Map<String, Object> map = new HashMap<>(); map.put("start", start);

map.put("size", size);

6.【强制】不允许直接拿 HashMap 与 Hashtable 作为查询结果集的输出。

说明：resultClass=”Hashtable”，会置入字段名和属性值，但是值的类型不可控。

7.【强制】更新数据表记录时，必须同时更新记录对应的 gmt_modified 字段值为当前时间。

8.【推荐】不要写一个大而全的数据更新接口。传入为 POJO 类，不管是不是自己的目标更新字段，都进行 update table set c1=value1,c2=value2,c3=value3; 这是不对的。执行 SQL 时，不要更新无改动的字段，一是易出错；二是效率低；三是增加 binlog 存储。

9.【参考】@Transactional 事务不要滥用。事务会影响数据库的 QPS，另外使用事务的地方需要考虑各方面的回滚方案，包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等。

10.【参考】<isEqual>中的 compareValue 是与属性值对比的常量，一般是数字，表示相等时带上此条件；<isNotEmpty>表示不为空且不为 null 时执行；<isNotNull>表示不为 null 值时执行。

说明：count(*)会统计值为 NULL 的行，而 count(列名)不会统计此列为 NULL 值的行。

2.【强制】count(distinct col) 计算该列除 NULL 之外的不重复行数，注意 count(distinct col1, col2) 如果其中一列全为 NULL，那么即使另一列有不同的值，也返回为 0。

3.【强制】当某一列的值全是 NULL 时，count(col)的返回结果为 0，但 sum(col)的返回结果为NULL，因此使用 sum()时需注意 NPE 问题。

正例：可以使用如下方式来避免 sum 的 NPE 问题：SELECT IF(ISNULL(SUM(g)),0,SUM(g)) FROM table;

4.【强制】使用 ISNULL()来判断是否为 NULL 值。说明：NULL 与任何值的直接比较都为 NULL。

1）NULL<>NULL 的返回结果是 NULL，而不是 false。

2）NULL=NULL 的返回结果是 NULL，而不是 true。

3）NULL<>1 的返回结果是 NULL，而不是 true。

5.【强制】在代码中写分页查询逻辑时，若 count 为 0 应直接返回，避免执行后面的分页语句。

6.【强制】不得使用外键与级联，一切外键概念必须在应用层解决。

说明：以学生和成绩的关系为例，学生表中的 student_id 是主键，那么成绩表中的 student_id 则为外键。如果更新学生表中的 student_id，同时触发成绩表中的 student_id 更新，即为级联更新。外键与级联更新适用于单机低并发，不适合分布式、高并发集群；级联更新是强阻塞，存在数据库更新风暴的风险；外键影响数据库的插入速度。

7.【强制】禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。

8.【强制】数据订正（特别是删除、修改记录操作）时，要先 select，避免出现误删除，确认无误才能执行更新语句。

9.【推荐】in 操作能避免则避免，若实在避免不了，需要仔细评估 in 后边的集合元素数量，控制在 1000 个之内。

10.【参考】如果有国际化需要，所有的字符存储与表示，均以 utf-8 编码，注意字符统计函数的区别。

说明：

SELECT LENGTH("轻松工作")； 返回为 12

SELECT CHARACTER_LENGTH("轻松工作")； 返回为 4

如果需要存储表情，那么选择 utf8mb4 来进行存储，注意它与 utf-8 编码的区别。

11.【参考】TRUNCATE TABLE 比 DELETE 速度快，且使用的系统和事务日志资源少，但 TRUNCATE

无事务且不触发 trigger，有可能造成事故，故不建议在开发代码中使用此语句。说明：TRUNCATE TABLE 在功能上与不带 WHERE 子句的 DELETE 语句相同。

说明：不要以为唯一索引影响了 insert 速度，这个速度损耗可以忽略，但提高查找速度是明显的；另外，即使在应用层做了非常完善的校验控制，只要没有唯一索引，根据墨菲定律，必然有脏数据产生。

2.【强制】超过三个表禁止 join。需要 join 的字段，数据类型必须绝对一致；多表关联查询时， 保证被关联的字段需要有索引。

说明：即使双表 join 也要注意表索引、SQL 性能。

3.【强制】在 varchar 字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度即可。

说明：索引的长度与区分度是一对矛盾体，一般对字符串类型数据，长度为 20 的索引，区分度会高达 90%以上，可以使用 count(distinct left(列名, 索引长度))/count(*)的区分度来确定。

4.【强制】页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决。

说明：索引文件具有 B-Tree 的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索引。

5.【推荐】如果有 order by 的场景，请注意利用索引的有序性。order by 最后的字段是组合索引的一部分，并且放在索引组合顺序的最后，避免出现 file_sort 的情况，影响查询性能。正例：where a=? and b=? order by c; 索引：a_b_c

反例：索引中有范围查找，那么索引有序性无法利用，如：WHERE a>10 ORDER BY b; 索引

a_b 无法排序。

6.【推荐】利用覆盖索引来进行查询操作，避免回表。

说明：如果一本书需要知道第 11 章是什么标题，会翻开第 11 章对应的那一页吗？目录浏览一下就好，这个目录就是起到覆盖索引的作用。

正例：能够建立索引的种类分为主键索引、唯一索引、普通索引三种，而覆盖索引只是一种查询的一种效果，用 explain 的结果，extra 列会出现：using index。

7.【推荐】利用延迟关联或者子查询优化超多分页场景。

说明：MySQL 并不是跳过 offset 行，而是取 offset+N 行，然后返回放弃前 offset 行，返回N 行，那当 offset 特别大的时候，效率就非常的低下，要么控制返回的总页数，要么对超过特定阈值的页数进行 SQL 改写。

正例：先快速定位需要获取的 id 段，然后再关联：

SELECT a.* FROM 表 1 a, (select id from 表 1 where 条件 LIMIT 100000,20 ) b where a.id=b.id

8.【推荐】SQL 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，如果可以是 consts

最好。说明：

1）consts 单表中最多只有一个匹配行（主键或者唯一索引），在优化阶段即可读取到数据。

2）ref 指的是使用普通的索引（normal index）。

3）range 对索引进行范围检索。

反例：explain 表的结果，type=index，索引物理文件全扫描，速度非常慢，这个 index 级别比较 range 还低，与全表扫描是小巫见大巫。

9.【推荐】建组合索引的时候，区分度最高的在最左边。

正例：如果 where a=? and b=? ，如果a 列的几乎接近于唯一值，那么只需要单建 idx_a

索引即可。

说明：存在非等号和等号混合时，在建索引时，请把等号条件的列前置。如：where c>? and d=? 那么即使 c 的区分度更高，也必须把 d 放在索引的最前列，即索引 idx_d_c。

10.【推荐】防止因字段类型不同造成的隐式转换，导致索引失效。

11.【参考】创建索引时避免有如下极端误解：

1）宁滥勿缺。认为一个查询就需要建一个索引。

2）宁缺勿滥。认为索引会消耗空间、严重拖慢更新和新增速度。

3）抵制惟一索引。认为业务的惟一性一律需要在应用层通过“先查后插”方式解决。

（1 表示是，0 表示否）。

说明：任何字段如果为非负数，必须是 unsigned。

注意：POJO 类中的任何布尔类型的变量，都不要加 is 前缀，所以，需要在<resultMap>设置从 is_xxx 到 Xxx 的映射关系。数据库表示是与否的值，使用 tinyint 类型，坚持 is_xxx 的命名方式是为了明确其取值含义与取值范围。

正例：表达逻辑删除的字段名 is_deleted，1 表示删除，0 表示未删除。

2. 【强制】表名、字段名必须使用小写字母或数字，禁止出现数字开头，禁止两个下划线中间只出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。说明：MySQL 在 Windows 下不区分大小写，但在 Linux 下默认是区分大小写。因此，数据库名、表名、字段名，都不允许出现任何大写字母，避免节外生枝。

正例：aliyun_admin，rdc_config，level3_name 反例：AliyunAdmin，rdcConfig，level_3_name

3. 【强制】表名不使用复数名词。

说明：表名应该仅仅表示表里面的实体内容，不应该表示实体数量，对应于 DO 类名也是单数形式，符合表达习惯。

4. 【强制】禁用保留字，如 desc、range、match、delayed 等，请参考 MySQL 官方保留字。

5. 【强制】主键索引名为 pk_字段名；唯一索引名为 uk_字段名；普通索引名则为 idx_字段名。说明：pk_ 即 primary key；uk_ 即 unique key；idx_ 即 index 的简称。

6. 【强制】小数类型为 decimal，禁止使用 float 和 double。

说明：float 和 double 在存储的时候，存在精度损失的问题，很可能在值的比较时，得到不正确的结果。如果存储的数据范围超过 decimal 的范围，建议将数据拆成整数和小数分开存储。

7. 【强制】如果存储的字符串长度几乎相等，使用 char 定长字符串类型。

8. 【强制】varchar 是可变长字符串，不预先分配存储空间，长度不要超过 5000，如果存储长度大于此值，定义字段类型为 text，独立出来一张表，用主键来对应，避免影响其它字段索引效率。

9. 【强制】表必备三字段：id, gmt_create, gmt_modified。

说明：其中 id 必为主键，类型为 bigint unsigned、单表时自增、步长为 1。gmt_create, gmt_modified 的类型均为 datetime 类型，前者现在时表示主动创建，后者过去分词表示被动更新。

10. 【推荐】表的命名最好是加上“业务名称_表的作用”。 正例：alipay_task / force_project / trade_config

11. 【推荐】库名与应用名称尽量一致。

12. 【推荐】如果修改字段含义或对字段表示的状态追加时，需要及时更新字段注释。

13. 【推荐】字段允许适当冗余，以提高查询性能，但必须考虑数据一致。冗余字段应遵循：

1） 不是频繁修改的字段。

2） 不是 varchar 超长字段，更不能是 text 字段。

正例：商品类目名称使用频率高，字段长度短，名称基本一成不变，可在相关联的表中冗余存储类目名称，避免关联查询。

14. 【推荐】单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。

说明：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。

15. 【参考】合适的字符存储长度，不但节约数据库表空间、节约索引存储，更重要的是提升检索速度。

正例：如下表，其中无符号值可以避免误存负数，且扩大了表示范围。

说明：防止没有做水平权限校验就可随意访问、修改、删除别人的数据，比如查看他人的私信内容、修改他人的订单。

2.【强制】用户敏感数据禁止直接展示，必须对展示数据进行脱敏。

说明：中国大陆个人手机号码显示为:158****9119，隐藏中间 4 位，防止隐私泄露。

3.【强制】用户输入的 SQL 参数严格使用参数绑定或者 METADATA 字段值限定，防止 SQL 注入， 禁止字符串拼接 SQL 访问数据库。

4.【强制】用户请求传入的任何参数必须做有效性验证。说明：忽略参数校验可能导致：

page size 过大导致内存溢出

恶意 order by 导致数据库慢查询

任意重定向

SQL 注入

反序列化注入

正则输入源串拒绝服务 ReDoS

说明：Java 代码用正则来验证客户端的输入，有些正则写法验证普通用户输入没有问题， 但是如果攻击人员使用的是特殊构造的字符串来验证，有可能导致死循环的结果。

5.【强制】禁止向 HTML 页面输出未经安全过滤或未正确转义的用户数据。

6.【强制】表单、AJAX 提交必须执行 CSRF 安全验证。

说明：CSRF(Cross-site request forgery)跨站请求伪造是一类常见编程漏洞。对于存在CSRF 漏洞的应用/网站，攻击者可以事先构造好 URL，只要受害者用户一访问，后台便在用户不知情的情况下对数据库中用户参数进行相应修改。

7.【强制】在使用平台资源，譬如短信、邮件、电话、下单、支付，必须实现正确的防重放的机制，如数量限制、疲劳度控制、验证码校验，避免被滥刷而导致资损。

说明：如注册时发送验证码到手机，如果没有限制次数和频率，那么可以利用此功能骚扰到其它用户，并造成短信平台资源浪费。

【推荐】发贴、评论、发送即时消息等用户生成内容的场景必须实现防刷、文本内容违禁词过滤等风控策略。

说明：单元测试在线上运行时，感觉像空气（AIR）一样并不存在，但在测试质量的保障上， 却是非常关键的。好的单元测试宏观上来说，具有自动化、独立性、可重复执行的特点。

A：Automatic（自动化）

I：Independent（独立性）

R：Repeatable（可重复）

2.【强制】单元测试应该是全自动执行的，并且非交互式的。测试用例通常是被定期执行的，执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。单元测试中不准使用 System.out 来进行人肉验证，必须使用 assert 来验证。

3.【强制】保持单元测试的独立性。为了保证单元测试稳定可靠且便于维护，单元测试用例之间决不能互相调用，也不能依赖执行的先后次序。

反例：method2 需要依赖 method1 的执行，将执行结果作为 method2 的输入。

4.【强制】单元测试是可以重复执行的，不能受到外界环境的影响。

说明：单元测试通常会被放到持续集成中，每次有代码 check in 时单元测试都会被执行。如果单测对外部环境（网络、服务、中间件等）有依赖，容易导致持续集成机制的不可用。

正例：为了不受外界环境影响，要求设计代码时就把 SUT 的依赖改成注入，在测试时用 spring

这样的 DI 框架注入一个本地（内存）实现或者 Mock 实现。

5.【强制】对于单元测试，要保证测试粒度足够小，有助于精确定位问题。单测粒度至多是类级别，一般是方法级别。

说明：只有测试粒度小才能在出错时尽快定位到出错位置。单测不负责检查跨类或者跨系统的交互逻辑，那是集成测试的领域。

6.【强制】核心业务、核心应用、核心模块的增量代码确保单元测试通过。

说明：新增代码及时补充单元测试，如果新增代码影响了原有单元测试，请及时修正。

7.【强制】单元测试代码必须写在如下工程目录：src/test/java，不允许写在业务代码目录下。说明：源码构建时会跳过此目录，而单元测试框架默认是扫描此目录。

8.【推荐】单元测试的基本目标：语句覆盖率达到 70%；核心模块的语句覆盖率和分支覆盖率都要达到 100%

说明：在工程规约的应用分层中提到的 DAO 层，Manager 层，可重用度高的 Service，都应该进行单元测试。

9.【推荐】编写单元测试代码遵守 BCDE 原则，以保证被测试模块的交付质量。

B：Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等。

C：Correct，正确的输入，并得到预期的结果。

D：Design，与设计文档相结合，来编写单元测试。

E：Error，强制错误信息输入（如：非法数据、异常流程、非业务允许输入等），并得到预期的结果。

10.【推荐】对于数据库相关的查询，更新，删除等操作，不能假设数据库里的数据是存在的， 或者直接操作数据库把数据插入进去，请使用程序插入或者导入数据的方式来准备数据。

反例：删除某一行数据的单元测试，在数据库中，先直接手动增加一行作为删除目标，但是这一行新增数据并不符合业务插入规则，导致测试结果异常。

11.【推荐】和数据库相关的单元测试，可以设定自动回滚机制，不给数据库造成脏数据。或者对单元测试产生的数据有明确的前后缀标识。

正例：在 RDC 内部单元测试中，使用 RDC_UNIT_TEST_的前缀标识数据。

12.【推荐】对于不可测的代码建议做必要的重构，使代码变得可测，避免为了达到测试要求而书写不规范测试代码。

13.【推荐】在设计评审阶段，开发人员需要和测试人员一起确定单元测试范围，单元测试最好覆盖所有测试用例。

14.【推荐】单元测试作为一种质量保障手段，不建议项目发布后补充单元测试用例，建议在项目提测前完成单元测试。

15.【参考】为了更方便地进行单元测试，业务代码应避免以下情况：

构造方法中做的事情过多。

存在过多的全局变量和静态方法。

存在过多的外部依赖。

存在过多的条件语句。

说明：多层条件语句建议使用卫语句、策略模式、状态模式等方式重构。

16.【参考】不要对单元测试存在如下误解：

那是测试同学干的事情。本文是开发手册，凡是本文内容都是与开发同学强相关的。

单元测试代码是多余的。系统的整体功能与各单元部件的测试正常与否是强相关的。

单元测试代码不需要维护。一年半载后，那么单元测试几乎处于废弃状态。

单元测试与线上故障没有辩证关系。好的单元测试能够最大限度地规避线上故障。

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

private static final Logger logger = LoggerFactory.getLogger(Abc.class);

2. 【强制】日志文件至少保存 15 天，因为有些异常具备以“周”为频次发生的特点。

3. 【强制】应用中的扩展日志（如打点、临时监控、访问日志等）命名方式：

appName_logType_logName.log。

logType:日志类型，如 stats/monitor/access 等；logName:日志描述。这种命名的好处： 通过文件名就可知道日志文件属于什么应用，什么类型，什么目的，也有利于归类查找。

正例：mppserver 应用中单独监控时区转换异常，如：

mppserver_monitor_timeZoneConvert.log

说明：推荐对日志进行分类，如将错误日志和业务日志分开存放，便于开发人员查看，也便于通过日志对系统进行及时监控。

4. 【强制】对 trace/debug/info 级别的日志输出，必须使用条件输出形式或者使用占位符的方式。

说明：logger.debug("Processing trade with id: " + id + " and symbol: " + symbol); 如果日志级别是 warn，上述日志不会打印，但是会执行字符串拼接操作，如果 symbol 是对象，会执行 toString()方法，浪费了系统资源，执行了上述操作，最终日志却没有打印。

正例：（条件）建设采用如下方式

if (logger.isDebugEnabled()) {

logger.debug("Processing trade with id: " + id + " and symbol: " + symbol);

}

正例：（占位符）

logger.debug("Processing trade with id: {} and symbol : {} ", id, symbol);

5. 【强制】避免重复打印日志，浪费磁盘空间，务必在 log4j.xml 中设置 additivity=false。正例：<logger name="com.taobao.dubbo.config" additivity="false">

6. 【强制】异常信息应该包括两类信息：案发现场信息和异常堆栈信息。如果不处理，那么通过关键字 throws 往上抛出。

正例：logger.error(各类参数或者对象 toString() + "_" + e.getMessage(), e);

7. 【推荐】谨慎地记录日志。生产环境禁止输出 debug 日志；有选择地输出 info 日志；如果使用 warn 来记录刚上线时的业务行为信息，一定要注意日志输出量的问题，避免把服务器磁盘撑爆，并记得及时删除这些观察日志。

说明：大量地输出无效日志，不利于系统性能提升，也不利于快速定位错误点。记录日志时请思考：这些日志真的有人看吗？看到这条日志你能做什么？能不能给问题排查带来好处？

8. 【推荐】可以使用 warn 日志级别来记录用户输入参数错误的情况，避免用户投诉时，无所适从。如非必要，请不要在此场景打出 error 级别，避免频繁报警。

说明：注意日志输出的级别，error 级别只记录系统逻辑出错、异常或者重要的错误信息。

9. 【推荐】尽量用英文来描述日志错误信息，如果日志中的错误信息用英文描述不清楚的话使用中文描述即可，否则容易产生歧义。国际化团队或海外部署的服务器由于字符集问题，【强制】

使用全英文来注释和描述日志错误信息。

( 一 ) 命名风格

1. 【强制】代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。 反 例 ：_name / name / $name / name_ / name$ / name  

2. 【强制】代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。

说明：正确的英文拼写和语法可以让阅读者易于理解，避免歧义。注意，即使纯拼音命名方式也要避免采用。

正例：alibaba / taobao / youku / hangzhou 等国际通用的名称，可视同英文。反例：DaZhePromotion [打折] / getPingfenByName() [评分] / int 某变量 = 3

3.  【强制】类名使用 UpperCamelCase 风格，但以下情形例外：DO / BO / DTO / VO / AO / PO / UID 等。

正例：MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion

反例：macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion

4.  【强制】方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格，必须遵从驼峰形式。

正例： localValue / getHttpMessage() / inputUserId

5. 【强制】常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。正例：MAX_STOCK_COUNT

反例：MAX_COUNT

6.  【强制】抽象类命名使用 Abstract  或 Base 开头； 异常类命名使用 Exception 结尾；测试类 命名以它要测试的类的名称开始，以 Test 结尾。

7. 【强制】类型与中括号紧挨相连来表示数组。正例： 定义整形数组 int[] arrayDemo;

反例： 在 main 参数中，使用 String args[]来定义。

8. 【强制】POJO  类中布尔类型的变量，都不要加 is 前缀，否则部分框架解析会引起序列化错误。反例： 定义为基本数据类型 Boolean isDeleted  的属性，它的方法也是 isDeleted()，RPC

一、2.5.1修改记录

1. 文章详情页面最后编辑放在页尾
2. 调整了后台区块设置颜色的界面
3. 二维码图片设置默认的宽度和高度
4. 处理留言和回复的时候，把留言或者评论的内容显示在回复框里面
5. 修复开放登录的图片地址
6. 手册文章的评论没有显示手册的查看链接
7. 调整php源码区块的样式
8. zui里面的弹出框里面的"好的"改为"确定"
9. 布局页面的操作统一改为图标按钮
10. 跳转页面需要加placeholder，提示用户输入链接
11. 关注我们改为区块实现，样式调整
12. 检查ie11下面的兼容性问题
13. php源码的ok文件提示不要放在文本框架里面
14. 全局样式菜单直接改成全局样式增加代码高亮
15. 如果站点类型是博客的话，把网站首页的链接去掉可以支持小图标
16. 产品的摘要改为简介
17. 类目管理放到类目的最下面
18. 类目维护后面增加x按钮，可以删除
19. 调整论坛帖子转移的逻辑
20. 调整上传模板页面的的样式
21. 源代码区块改为html源代码，设置选项，直接语法高亮
22. 新闻，产品列表的删除放在最后面
23. 把IE6提示代码放到js里加载，同时简化提示内容
24. 修复火狐下面导航错位问题
25. 解决后台文章管理模块，左边栏 类目浏览 如果文章类目过多会被遮盖，且无法向下滚动的问题

二、下载地址

三、安装和升级文档

四、演示

后台演示： http://demo.chanzhi.org/chanzhiadmin.php

五、新功能截图

区块颜色自定义预览

区块颜色自定义

代码高亮

关于我们页面区块设置

1、实现模板和主题风格的概念
2、将前台的模板文件独立出来
3、实现模板的导入功能
4、模板体系可以定义支持的区块和布局列表
5、增加插件管理机制
6、后台布局的区块、导航、手册等列表页面的排序改为拖动排序 
7、增加php源代码区块
8、源代码区块增加代码编辑器
9、区块增加更多颜色的配置
10、自定义区块也支持更多链接
11、公司简介区块还原更多链接
12、留言、评论支持回复功能
13、留言、评论列表显示所有回复
14、发表评论的时候可以选择是否接收邮件通知
15、评论被回复的时候，发送邮件通知评论作者
16、后台留言和评论通过之后也可以删除
17、设置产品的价格货币单位使用符号
18、调整没有任何参数的产品的详情页面
19、产品简介添加编辑器
20、用户可以直接定义一个全局的样式
21、调整手机版本下面幻灯的显示样式
22、登录注册的代码不应当出现在文档开始的地方
23、编辑手册的时候，记住当时点击的锚点
24、将文章详情页面底部的空白标签去掉
25、博客、论坛、手册功能关闭的时候，站点地图不显示这些模块
26、重新调整论坛的主题转移功能
27、类目维护页面增加添加按钮，可以新增一个类目框
28、类目、文章、主题可以是一个链接，当浏览该类目时，跳转到其他的链接地址
29、后台的主题、帖子、留言的删除改用zui里面的对话框
30、修改ie6的检查提示方式
31、二维码只有打开的时候再请求
32、图片浏览只能后台才可以使用，前台不能使用
33、日志文件增加.php扩展名
34、附件目录、system目录每个都创建空白的index.php文件
35、升级的时候去掉ok文件的检查
36、手册文章显示最后更新时间
37、后台的文章、博客、产品列表增加图片链接
38、调整帖子详情附件上传的表单样式
39、调整后台的文章、博客、产品等模块点开的附件上传表单修改样式
40、升级到2.5的时候，将之前的日志文件删除掉
41、备案信息增加链接
42、幻灯的链接应当指定是否是新开窗口
43、调整ie11下载附件的逻辑
44、后台的用户检索可以模糊检索
45、公司联系方式增加公司网址
46、处理QQ登录相关报错

二、下载地址

三、安装和升级文档

四、演示

后台演示： http://demo.chanzhi.org/chanzhiadmin.php

五、功能截图

1.评论留言可重复回复

2.可以拖拽排序

3.模板设置

4.代码编辑器

后台博客、产品、文章列表增加按照类目浏览功能
解决新版本的火狐二级导航错位问题
优化产品列表和详情页面的样式
论坛版块描述支持html标签显示
修复幻灯片删除第一个链接按钮后无法保存的bug
处理部分面包屑里面的类目地址bug

解决部分图标无法显示bug
调整对话框的默认样式
区块增加更多链接
优化编辑区块操作体验，编辑后停留在编辑页面
调整文章的来源字段类型和显示效果
前端优化：代码把ie8相关的js脚本打包成一个ie8.js
前端优化：将treeview.js和treeview.css打包到all.css和all.js中
将前台每个列表页面默认记录数改成从配置项获取
附件列表不再显示编辑器上传的图片
优化评论和留言列表的样式
去掉论坛主题里面p标记的margin
调整蝉知系统默认的字体大小
修改布局的区域名称使之更容易理解
zui里面去掉p标记的margin
减少布局中列与列之间的间距
导航设置默认折叠起来
版块编辑器增加源代码标签
版块的描述字段长度调成text类型。
解决编辑器上传附件使用现有的图片时，缩略图地址错误的bug
调整前台首页友情链接的样式
留言和评论增加需要审核之后才会显示的提示。
幻灯功能优化： 优化了后台管理界面，排序不再需要手动点击保存排序按钮，
解决通过之前评论时，留言也会被通过的bug
后台删除主题或者回帖的时候添加确认提示
前台主题的维护选项增加转移功能
增加logo删除功能

二、下载地址

三、安装和升级文档

四、演示

后台演示： http://demo.chanzhi.org/chanzhiadmin.php

五、功能截图

PS:ZUI构建于众多优秀的开源项目之上

向他们致谢！

1、这次升级我们修改了 蝉知系统版权，请大家仔细阅读。

     蝉知系统版权： http://www.chanzhi.org/book/chanzhieps/58_license.html

2、后台站点设置添加了首页关键字，首页标题算法改为首页关键字+站点名称，升级后需要大家根据需要重新设置一下。

一、2.3修改记录

1. 博客页面应当增加对所有页面区块的支持
2. 解决文章详情页面微博推广按钮不删除验证代码就不能显示问题
3. 解决宽屏主题登录注册按钮不显示问题
4. 解决部署在二级目录时微信的接入地址的bug 
5. 解决后台的用户列表中重复显示的bug 
6. 修复新浪会员链接
7. 单页可以控制页面的布局
8. 优化时间显示，去除00:00的显示
9. 文章的来源增加翻译选项
10. 二维码的图片缩小了一些
11. 后台设置开放登录的图标用亮色的
12. 删除zepto.js文件
13. 调整蝉知默认的字体的大小
14. 留言的图标采用亮色的
15. 增加检查更新的功能
16. 安装升级界面添加蝉知协议
17. 论坛版块和博客类目的别名不能使用数字
18. 论坛后台的回帖链接应当新开页面
19. 个人中心我的主题里面，最新回帖显示真实姓名
20. 论坛发贴的时候，判断所属版块是否存在且可读
21. 论坛版块列表页面的版主显示真实姓名
22. 管理员或者版主身份在前台显示的时候应当给予标识
23. 论坛增加帖子转移功能
24. 后台单独增加一个首页关键词的设置
25. 升级程序需要处理之前的站点描述信息，将html标签去掉
26. 产品购买链接新窗口打开
27. 提供了iis下面的重写规则
28. 头部区域的logo，站点口号，登录注册也用区块显示
29. 整理英语下面的翻译
30. 首页布局调整，使之能显示最新产品
31. 编辑器里面的图片库，文件库可以从我们附件表里面选择
32. 对于禁用的会员，希望后台可以增加解除禁用功能
33. 公司简介区块更多链接放在标题右侧
34. 文章列表显示的条目数可自己设置。
35. 站点增加类型设置，可以选择企业门户或者个人门户
36. 幻灯文字和图片给予提示
37. 幻灯可以有多个按钮
38. 每一个幻灯都可以指定文字的颜色和背景色
39. 幻灯可以使用纯色来实现
40. 实现产品自定义属性功能
41. 解决一键安装包qq开放登录的问题

二、下载地址

源码包： http://dl.xirangit.com/eps/2.3/chanzhiEPS.2.3.zip

三、安装和升级文档

安装文档： http://www.chanzhi.org/book/chanzhieps/5.html

升级文档： http://www.chanzhi.org/book/chanzhieps/68.html

四、演示

前台演示： http://demo.chanzhi.org

后台演示： http://demo.chanzhi.org/chanzhiadmin.php

五、功能截图

  1 调整评论页面的文案。

  7 把oauth类的get方法去掉file_get_contents方式，只用CURL方式。

  8 解决php magic_quotes_gpc 打开时中文内容存储失败的bug。 

二、下载地址

源码包： http://dl.xirangit.com/eps/2.2/chanzhiEPS.2.2.1.zip

安装包： http://dl.xirangit.com/eps/2.2/chanzhiEPS.2.2.1.exe

三、安装和升级文档  

安装文档： http://www.chanzhi.org/book/chanzhieps/5.html

升级文档： http://www.chanzhi.org/book/chanzhieps/68.html

前台演示： http://demo.chanzhi.org

后台演示： http://demo.chanzhi.org/chanzhiadmin.php

一、修改记录

1. 后台设置logo页面调整
2. 论坛帖子用户信息调整
3. 调整反馈，将留言、评论、主题、回帖，将其集中在一起。
4. 添加微信公众号接入功能
5. 添加公众号会员查看功能
6. 添加公众号消息管理功能
7. 添加公众号菜单、关键字、订阅回复、默认回复的管理功能
8. 新增宽屏主题
9. 前台添加微信公众号和手机访问二维码显示
10. 禁止百度自动转码 。
    

二、新特性截图

2.1 前台显示微信公众号的二维码以及当前网址的二维码。

2.2 后台的微信功能设置

2.3 微信界面截图

三、下载地址

源码包： http://dl.xirangit.com/eps/2.2/chanzhiEPS.2.2.zip

安装包： http://dl.xirangit.com/eps/2.2/chanzhiEPS.2.2.exe

四、安装和升级文档  

安装文档： http://www.chanzhi.org/book/chanzhieps/5.html

升级文档： http://www.chanzhi.org/book/chanzhieps/68.html

前台演示： http://demo.chanzhi.org

后台演示： http://demo.chanzhi.org/chanzhiadmin.php

五、蝉知系统微信集成手册

蝉知系统微信集成手册： http://www.chanzhi.org/book/weixin.html

1. 区块增加图标设置功能
2. 布局设置增加区块宽度设置功能
3. 触屏设备访问时幻灯片增加拖动支持
4. 论坛帖子最后编辑者改为真实姓名
5. 关于我们页面使用区块把联系我们放在右侧
6. 批量维护手册章节的时候添加发布时间
7. 编辑手册文章的时候增加发布时间的字段
8. 重新调整h1-h6标签的字体大小
9. 解决置顶帖子用户姓名问题
10. 修改版权提示的格式
11. 修复分页的bug
12. 幻灯排序在ie10下面有问题。
13. 修复ie10下面蓝色风格的问题
14. 精简文章详情页面的上一篇下一篇的导航文字
15. 调整留言页面回复内容的缩进和字体大小
16. 优化移动版本头尾的处理
17. 管理员身份回帖的时候应当使用全编辑器
18. 论坛帖子发贴框的宽度调整。把只读放在后面。
19. 调整论坛列表页面各列的宽度
20. 以管理员身份发表评论或者留言，默认状态为通过。
21. 后台管理员回复一篇评论或留言之后，默认将其状态改为通过
22. 修改邮箱默认配置，将腾讯邮箱默认改为465 
23. 如果发贴用户已被删除，帖子列表页面的最后回复取用户名
24. 论坛出现版主的地方也都显示真实姓名
25. 将user模块的getRealName()方法改为getRealNamePairs()
26. 调整模拟的alert和confirm框的样式
27. 论坛帖子列表的时候显示用户的真实姓名
28. 留言者区分是否是登录用户
29. 论坛的板块设置提示需要二级板块
30. 区块首页底部的命名改为中部。
31. 调整文章，产品无类目时的交互方式
32. 重置密码功能把resetKey，resetTime合成一个字段
33. 论坛控制图片大小

二、手机访问截图

三、下载地址

源码包： http://dl.xirangit.com/eps/2.1/chanzhiEPS.2.1.zip
安装包： http://dl.xirangit.com/eps/2.1/chanzhiEPS.2.1.exe

四、安装和升级文档  

安装文档： http://www.chanzhi.org/book/chanzhieps/5.html
升级文档： http://www.chanzhi.org/book/chanzhieps/68.html
前台演示： http://demo.chanzhi.org

后台演示： http://demo.chanzhi.org/chanzhiadmin.php

一、服务条款的确认和接纳

(2) 当您使用服务时，您需阅读并且同意 《蝉知企业门户系统授权协议》；

(3) 当您使用服务时，您需知晓并且同意此《云蝉知在线使用协议》；

(5) 若您继续使用系统提供的服务，则表明您接受新的协议。

二、服务内容

(1) 此协议所述服务仅在云蝉知网站内有效。云蝉知网站是指http://www.chanzhi.net及其所属网页；

三、帐户

四、费用

(1) 在您正式使用云蝉知服务之前，您需要自己申请域名。
(2) 云蝉知现在为大家提供免费服务，免费用户可以创建三个站点。每个站点可使用100M空间(包括附件、图片和数据库），每个月10GB流量。如果超出存储空间或者流量，云蝉知网站有权对该站点的访问进行限制。
(3) 云蝉知后续会提供功能更强的收费版本，收费标准届时会在云蝉知网站公布。云蝉知保留对收费模式和具体金额调整的权利，涉及收费服务，将至提前30天的时间通过电子邮件的形式通知帐户。

五、服务终止

有下列情形之一的，云蝉知网站有权随时暂停、终止、取消或拒绝帐户服务。

(1) 帐户违反了此协议或已在约定范围内的任一条款；
(2) 根据此协议相关说明而终止服务；
(3) 利用云蝉知网站的发布功能滥发重复信息；
(4) 未经请求或授权向云蝉知网站帐户发送大量与业务不相关的信息；
(5) 冒用其他企业的名义发布商业信息，进行商业活动；
(6) 攻击云蝉知网站的数据、网络或服务；

(7) 盗用他人在云蝉知网站上的帐户名和密码。

以下信息是严格禁止并绝对终止帐户服务，同时不退回购买费用的：

(1) 有关宗教、种族或性别的贬损言辞；
(2) 骚扰、滥用或威胁其他帐户；
(3) 侵犯任何第三方著作权、专利、商标、商业秘密或其它专有权利、发表权或隐私权的信息；
(4) 其它任何违反互联网相关法律法规的信息。

六、云蝉知用户的权利和义务

(1) 云蝉知服务生效后，帐户就可享受相应服务内容；
(2) 云蝉知用户在使用云蝉知网站提供的相应服务时，必须保证遵守当地及中国有关法律法规的规定；
不得利用该网站进行任何非法活动；遵守所有与使用该网站有关的协议、规定、程序和惯例；
(3) 云蝉知用户对输入数据的准确性、可靠性、合法性、适用性等负责；

七、云蝉知的权利和义务

(1) 云蝉知尽最大努力来保证服务的正常访问以及数据的备份。
(2) 云蝉知为收费用户提供相应的咨询、技术支持等服务。

(3)对于因不可抗力造成的服务中断、链接受阻或其他缺陷(包括但不限于自然灾害、社会事件以及因网站所具有的特殊性质而产生的包括系统崩溃、数据丢失、黑客攻击、电信部门技术调整导致的影响、政府管制而造成的暂时性关闭在内的任何影响网络正常运营的因素)，云蝉知网站不承担任何责任，但将尽力减少因此而给会员造成的损失和影响；
(4) 云蝉知网站对用户因使用云蝉知服务而造成的损失不负法律责任。不论什么情况下对用户因使用云蝉知服务而造成的直接、间接、偶尔的、特殊的惩罚性的损害或其他一切损害概不负法律责任；
(5) 如因云蝉知原因，造成服务的不正常中断，青岛息壤不承担任何责任，青岛息壤也不承担由此致使会员蒙受的其它方面的连带损失；

八、隐私与保密

(1) 您注册时所填写的个人信息仅限于青岛息壤与您之间联系使用，青岛息壤不得将其用于商业目的。
(2) 您通过云蝉知产生的任何数据都属于您所有。除非您主动要求我们协助您排查问题，否则青岛息壤的所有员工无权查看、编辑、复制、删除您的任数据。

九、最终解释权

青岛息壤网络信息有限公司对云蝉知保有所有活动、限制等的最终解释权。

蝉知企业门户系统是由业内资深开发团队开发的一款专向企业营销使用的企业门户系统，企业使用蝉知系统可以非常方便地搭建一个专业的企业营销网站，进行宣传，开展业务，服务客户。蝉知系统内置了文章、产品、论坛、评论、会员、博客、帮助等功能，同时还可以和微信进行集成绑定。功能丰富实用，后台操作简洁方便。蝉知系统还内置了搜索引擎优化必备的功能，比如关键词，摘要，站点地图，友好路径等，使用蝉知系统可以非常方便的搭建对搜索引擎友好的网站。

为什么 叫做 蝉知？

蝉是中国传统的吉祥物之一，象征着闻达和财富，非常符合企业作为盈利组织的特点。所以我们为这套系统起名为蝉知，希望通过这款开源免费的系统可以帮助众多的中小企业快速方面的建立自己的企业网站，进行宣传营销。

为什么 来 做 蝉知？

蝉知团队还有其他的开源产品，我们在维护自己的产品的时候，也存在这样的需求：我们需要一个网站来对产品进行宣传，能够给用户提供技术支持，方便用户下载等等。我们也曾经想用市面上的其他cms系统来搭建，但后来发现要做大量的改动定制，还不如自己写一个。所以我们在四年多的时间里面一点点的完善自己的产品网站。与此同时我们在和客户接触的时候，发现企业的网站大都不敢恭维：技术陈旧、载入速度缓慢、不利于seo、后台晦涩难懂。于是我们就产生了做一个企业门户系统来解决这个问题的想法，于是就是了蝉知这个产品。

为什么以开源的方式来发布？

蝉知源代码完全开放，不限制商用。我们之所以坚持以开源的方式来发布蝉知系统，是因为我们坚信开放才是正道。只有开放的系统才更具有生命力，用户使用起来才更加放心。

为什么选择蝉知门户系统来搭建企业网站？

现在做一个企业营销网站可以有很多选择，比如使用国外开源的wordpress, dupal, jommla等。国内的有dedecms, phpcms等cms系统。还有很多在线建站的公司。如果费用充足的话，可以选择建站公司来做（建站公司也是使用上述的这些系统来帮你搭建，比较坑）。那么蝉知系统和这些系统相比有什么特点呢？

1. 首先，我们是专门做企业营销网站。

• 现在做网站，都是在cms系统上面改。而蝉知系统是专门面向企业营销网站的，所以功能更具有针对性。我们内置了文章、产品、会员、论坛、评论、帮助、博客等诸多功能，完全可以应对企业营销网站的各种需求。
• 蝉知系统特别重视搜索引擎优化，内置了关键词管理、摘要、站点地图等功能。同时只要环境支持url重写，就可以生成搜索引擎非常喜欢的路径结构，比如/news/123.html这样的路径。
• 蝉知系统后续会内置基本的统计数据，哪怕网站只有一个用户访问，也要让您清清楚楚的知道网站有人在访问。这样网站不再是死的的网站。

2. 其次， 蝉知 系统 是 真正 的 开源 免费

• 蝉知系统是目前唯一开源免费的企业门户系统。
• 蝉知系统以LGPL协议发布，代码完全开放，是真正的开源。（有很多号称开源的cms系统，其实都是假的。)
• 蝉知系统不限制商用，也不会为了推我们后续的一些收费功能或者服务故意的在产品中做很多限制。
  

3. 蝉知系统技术先进，注重用户体验

• 蝉知系统使用自主开发的框架搭建，架构更加合理。
• 内置完善的扩展机制，方便企业后续的二次开发。蝉知系统的首要定位是帮助企业解决营销问题，当营销问题解决之后，企业会考虑在蝉知系统上搭建自己的业务系统，比如报名、订单之类的业务。这时候在蝉知系统基础上进行二次开发是非常容易的事情。
• 蝉知团队不断的学习业内先进的设计理念，给大家提供简洁方便的产品。

4. 使用 支持 有 保障

• 别人做开源，也许只是兴趣。而我们做开源，是专职在做，以正规的公司形式来运作。
• 我们有将近十年的开源软件开发和维护经验，对开源软件的后续开发、支持有丰富的经验。
• 我们团队和系统足够开放，后续我们会着手打造一个面向企业营销市场的小生态系统，吸引第三方的设计师、网站建设公司参与。

so，不要再犹豫，新时代做企业营销，首选蝉知门户系统，靠谱！