1.应用中不可直接使用日志系统（Log4j、Logback）中的API，而应依赖使用日志框架SLF4J中的API,使用门面模式的日志框架，有利于维护和各个类的日志处理方式统一
2.日志文件推荐至少保存15天，因为有些异常具备以‘周’为频次发生的特点
3.应用中的扩展日志命名方式以：appName_logType_logName.log，好处是日志日志文件属于什么应用，什么类型，什么目的，有利于归类查找;方便错误日志和业务日志查找。
logType(推荐 status/desc/monitor/visit等)
4.日志输出级别trace/debug/info等 必须使用条件输出形式或者使用占位符的方式，避免直接使用字符串拼接操作
(条件) if(logger.isDebugEnabled()){
logger.debug("the log id is "+id+"date is :"+date);
}
(占位符) logger.debug("the log id is {} and date is {} ",id,date);
5.避免重复打印日志，浪费磁盘空间，务必在log4j.xml中设置additivity=false
6.异常信息应该包括两类信息：案发现场信息；异常堆栈信息
如： logger.error("the id {}and date{} is ", id, date + "_", e.getMessage(), e); 如果不处理，使用关键字throws往上抛
7.warn日志级别记录用户输入参数错误的情况，error级别只记录系统逻辑错误、异常等重要的错误信息
谨慎地记录日志。生产环境禁止输出debug日志；有选择的输出info日志，注意warn日志记录刚上线业务行为信息的数量。
8.隶属于用户个人的页面或者功能必须进行权限控制检验
9.用户敏感数据禁止直接展示
10.用户输入的SQL参数严格使用参数绑定或者METADATA字段值限制，防止SQL注入，禁止字符串拼接SQL访问数据库
11.用户请求传入的任何参数必须做有效性验证。 说明:忽略参数校验可能导致:
page size过大导致内存溢出；恶意order by 导致数据库慢查询；任意重定向；SQL注入；反序列化注入正则输入源串拒绝服务ReDos
12.禁止向 HTML 页面输出未经安全过滤或未正确转义的用户数据。表单、AJAX 交必须执行 CSRF 安全过滤 CSRF(Cross-site request forgery)跨站请求伪造是一类常见编程漏洞。对于存在 CSRF 漏洞的应用/网站，攻击者可以事先构造好 URL，只要受害者用户一访问，后台便在用户 不知情情况下对数据库中用户参数进行相应修改。
13，在使用平台资源，譬如短信、邮件、电话、下单、支付，必须实现正确的防重放限制， 如数量限制、疲劳度控制、验证码校验，避免被滥刷、资损。
14.发贴、评论、发送即时消息等用户生成内容的场景必须实现防刷、文本内容违禁词过 滤等风控策略。