ASPIRE

[collect]框架的作用

=Start=

缘由：

学习提高

正文：

参考解答：

@Intopass

一、首先，到底什么是框架？

①首先从DRY原则开始说起
Don’t Repeat Yourself，不要重复你的代码。

1）最初级的DRY：语法级别
2）进阶的DRY原则：方法级别
3）继续进阶的DRY原则：类型级别
4）继续继续进阶的DRY原则：多个类组合级别

②设计模式，更高层级的DRY应用
设计模式是经过长时间编码之后，经过系统性的总结所提出的针对某一类问题的最佳解决方案，又称之为最佳实践。而在小规模的编码工作中，其实并不需要什么设计模式，只有大型程序才有设计模式发挥的空间，所以我们需要借助一些特定领域有足够规模的问题来了解一下设计模式存在的必要性。

③框架，是设计模式的集大成者，是DRY原则的最高应用

二、那么问题就来了，框架到底是什么？要不要学，怎么学？

下面以JavaWeb开发为例再进行一些说明，并顺便简单介绍一下JavaWeb的一些脉络。

① 静态网页时代
② Servlet时代
③ JSP包打天下的时代
④ Servlet + JSP 时代
⑤ MVC模式时代

一次典型的访问是这样的流程：
1. 用户输入网址或点击链接或提交表单，浏览器发起请求
2. –> 通过互联网，通过HTTP协议 –>
3. Tomcat接受到HTTP请求，生成HttpServletRequest对象，根据Web.xml的配置，调用开发者编写的HttpServlet，HttpServlet根据请求内容，调用JavaBean获取数据，JavaBean从数据库获取数据，返回HttpServlet，HttpServlet将数据转发给JSP，JSP负责将数据渲染为HTML，由Tomcat负责将HTML转化为HTTP响应，返回客户端。
4. –> 通过互联网，通过HTTP协议 –>
5. 客户端浏览器接收到HTTP响应，浏览器将HTML渲染为页面，并运行其中可能存在的JavaScript进一步调整界面。

⑥ JavaWeb框架
⑦ 所以当然要学框架，要用框架，那么要怎么学？
1. 用框架要知其然，还要知其所以然，要大体明白框架实现一个功能特性的原理，不能只是会用，只是觉得很神奇就可以了。就拿前面的Hibernate + Spring声明式事务为例，要弄明白框架这部分是怎么实现的。
2. 首先要夯实你的语言基础，如JavaSE基础，语法掌握，用法掌握，有些同学语法还不熟练就开始学框架，等于地基没打就起高楼，你可能会快一步，但是迟早要遇到瓶颈，甚至摔跟头。
3. 那么何时开始学习框架？我不建议新手一开始就直接使用框架。就好像一开始学习编程语言，大家都不推荐直接使用IDE，一定要用命令行自己编译运行几个文件之后，了解清楚了之后才可以使用IDE，要不然对于底层原理不了解，遇到问题没法自己手动排查。
4. 使用框架也是一样，如果不是自己写多了重复性的代码，就很难理解框架为什么要这么设计。如果不尝试几种不同的实现，就很难理解框架为了灵活性而做出的设计和扩展点。如果不写几十个权限检查语句，就很难理解AOP到底有什么好处。
5. 框架这么好，我该全部使用框架吗？首先只有在规模以上的程序中，才有应用框架的必要，一个简单的程序没必要使用框架，当然如果你很熟练，使用也无所谓。
6. 要学习一下框架的核心源代码，要为扩展框架做好准备，因为虽然框架基本上还算灵活，但是面对错综复杂的业务需求，永远不可能面面俱到，而你不了解框架的话，可能会给你实现业务需求造成麻烦。这也是有些人坚持使用Servlet+JSP原生开发，而不是用框架的理由。
7. 只要程序大了，归根究底还是要使用框架的，不是用别人写好的，就是自己写一套。这里我不建议自己写，不要重复造轮子，总有专业造轮子的。你草草写就的往往不如别人已经千锤百炼的代码。除非你是为了学习与研究的目的，自己写，那就是一件很好的事情。

==

@Harry Zhu、fleuria、pilot

【框架有其自身的适用场景，是瑞士军刀，非妇孺皆宜】
【框架可以让你在保证代码质量的基础上，拥有更多时间来关注自身的业务逻辑与代码】
【框架有学习曲线，有时候，框架学习的难度比手写代码自己实现的难度要高不少】

框架做的事情，就是自带胶水，做一些脏活累活替我们集成这些组件，降低偶发复杂度，我们可以专心往里面填业务。

规定了开发者写哪些代码／不写哪些代码，怎么写代码——这就是框架主要解决的问题。

规范代码布局，约束实现方式。

  • 如果追求开发速度快，ROR
  • 如果追求方便Full Stack， Django
  • 如果追求学习简单上手， PHP框架任选
  • 如果直接瞄准FB，TB，BAT，追求性能至上，大团队开发，企业铂金镶钻级开发，Java框架任选
参考链接：

=END=

Docker

,
, ,

《 “[collect]框架的作用” 》 有 18 条评论

  4. Spring AOP 的实现机制
    http://www.importnew.com/28342.html
    `
    AOP（Aspect Orient Programming），一般称为面向切面编程，作为面向对象的一种补充，用于处理系统中分布于各个模块的横切关注点，比如事务管理、日志、缓存等等。AOP实现的关键在于AOP框架自动创建的AOP代理，AOP代理主要分为静态代理和动态代理，静态代理的代表为AspectJ；而动态代理则以Spring AOP为代表。静态代理是编译期实现，动态代理是运行期实现，可想而知前者拥有更好的性能。本文主要介绍Spring AOP的两种代理实现机制，JDK动态代理和CGLIB动态代理。

    静态代理是编译阶段生成AOP代理类，也就是说生成的字节码就织入了增强后的AOP对象；动态代理则不会修改字节码，而是在内存中临时生成一个AOP对象，这个AOP对象包含了目标对象的全部方法，并且在特定的切点做了增强处理，并回调原对象的方法。

    Spring AOP中的动态代理主要有两种方式，JDK动态代理和CGLIB动态代理。JDK动态代理通过反射来接收被代理的类，并且要求被代理的类必须实现一个接口。JDK动态代理的核心是InvocationHandler接口和Proxy类。

    如果目标类没有实现接口，那么Spring AOP会选择使用CGLIB来动态代理目标类。CGLIB（Code Generation Library），是一个代码生成的类库，可以在运行时动态的生成某个类的子类，注意，CGLIB是通过继承的方式做的动态代理，因此如果某个类被标记为final，那么它是无法使用CGLIB做动态代理的，诸如private的方法也是不可以作为切面的。
    `

    回复

  6. Netty4 学习笔记之四: Netty HTTP服务的实现
    https://blog.csdn.net/qazwsxpcm/article/details/78364023
    https://github.com/xuwujing/Netty-study/tree/master/Netty-httpServer/src/main/java/com/pancm/netty/server

    基于Netty4构建HTTP服务—-浏览器访问和Netty客户端访问
    https://blog.csdn.net/wangshuang1631/article/details/73251180

    Netty 简单的HTTP服务器
    https://www.cnblogs.com/luangeng/p/7875710.html

    Netty入门教程2——动手搭建HttpServer
    https://www.jianshu.com/p/ed0177a9b2e3

    （高级篇 Netty多协议开发和应用）第十章-Http协议开发应用（基于Netty的HttpServer和HttpClient的简单实现）
    https://www.cnblogs.com/crazylqy/p/4901820.html

    回复

  8. netty简介及HTTP实现Demo
    https://www.jianshu.com/p/cfd2c037dd7b
    `
    netty的开发流程

    无论是基于netty进行HTTP服务器开发，还是进行socket开发，抑或是长连接开发，netty代码的开发流程主要有以下三个步骤：
    1.编写服务器，定义boosGroup和workerGroup，启动ServerBootstrap
    2.在服务器里面使用Handler或childHandler去启动Initailizer，在Initailizer里关联着请求的诸多handler
    3.在handler里面覆写netty提供的特定的事件回调方法
    `
    Netty学习笔记
    https://blog.gmem.cc/netty-study-note

    回复

  9. 公司为什么需要建立一套统一的开发框架？
    http://www.pmtoo.com/article/53583.html
    `
    弊端一：自我繁衍
    在公司快速的发展过程中，往往会出现这样一个链条。新增一块业务 —> 招聘一位高级技术人员 —> 围绕这位同事组建一只技术团队 —> 该业务基本由这只团队负责。然后就形成了一个闭环。当需要跟其他业务进行交互时，经常是技术负责人之间自行决定。（我曾经经历过一个项目，同样一个业务接口，同时提供 RPC，HTTP，MQ 等多种方式，为了给不同的项目提供基础服务）。

    弊端二：管控壁垒
    随着业务规模的快速发展，这个团队很快的形成了一个部门，团队决策者通常会从自身利益考量，希望尽量减少对外部门的依赖，无论是技术选型，规范建立，组件选取，运行环境都能够自行掌控。（在这里讲一个笑话，在一家公司怎么成为中层领导呢？很简单，招聘足够多的下属就可以了）。

    弊端三：断崖效应
    当这样的技术氛围一旦形成，单个员工对单个项目的影响就会变的非常巨大。一个产品经常会因为一两个核心员工的离职难以为继，最后不得不重新开发新的产品。

    弊端四：资源浪费
    当每个团队都在试图构建自己完整的研发流程时。中间的技术研究，产品研发，运维管理就会出现非常多的资源浪费。

    弊端五：难以考核
    怎么衡量一个川菜厨师和一个鲁菜厨师谁更优秀？当每个团队都采用不同技术栈，不同的技术组件，不同的维护方式和规范时。已经无法从产出效率来判断一个团队的绩效。KPI 指标也就非常难以设立。

    统一开发框架的优势
    1. 避免重复性技术研究——节约人力成本
    2. 标准化技术规范——提升产品项目质量
    3. 进行技术沉淀——提升公司整体技术能力，避免陷入一个人的能力决定一个项目
    4. 可衡量的研发投入——对研发团队的有效管理和考核
    `

    回复

  10. 什么是框架？
    https://paper.tuisec.win/detail/afa232669001cbb
    https://toutiao.io/posts/z4gicm/preview
    https://insights.thoughtworks.cn/what-is-software-framework/
    `
    在编程领域，软件框架是指一种抽象形式，它提供了一个具有通用功能的软件，这些功能可以由使用者编写代码来有选择的进行更改，从而提供服务于特定应用的软件。软件框架提供了一种标准的方式来构建并部署应用。

    软件框架是一种通用的、可复用的软件环境，它提供特定的功能，作为一个更大的软件平台的一部分，用以促进软件应用、产品和解决方案的开发工作。软件框架可能会包含支撑程序、编译器、代码、库、工具集以及 API，它把所有这些部件汇集在一起，以支持项目或系统的开发。

    规矩即自由。孔子把“从心所欲，不逾矩”当做自己的最佳状态，其实很多事都是这样。一旦深刻理解了设计和使用框架的思维模式，你将迎来一个实质性的提升。

    在我工作的前五年，编程时很“聪明”，用技巧解决了很多问题，但之后的十五年（恰好在那一年我知道了框架的概念），我爱上了规矩，不但自己给自己（根据血泪教训）立各种规矩，而且从别人那里借鉴了很多规矩，无论是宏观的还是微观的。可以说，规矩就是固化的好习惯，虽然有时候也会成为阻碍，但是如果你想在编程领域工作到退休，那么这些规矩就是你表面上最大的资产，而对这些规矩的来龙去脉的理解和领悟，则是你深层次中最大的资产。
    `

    回复

  11. 从零开始搭建创业公司后台技术栈
    http://www.phppan.com/2018/04/svr-stack/
    `
    语言： 用了哪些开发语言，如：c++/java/go/php/python/ruby等等；
    组件：用了哪些组件，如：MQ组件，数据库组件等等；
    流程：怎样的流程和规范，如：开发流程，项目流程，发布流程，监控告警流程，代码规范等等；
    系统：系统化建设，上面的流程需要有系统来保证，如：规范发布流程的发布系统，代码管理系统等等；

    一、各系统组件选型
    1、项目管理/Bug管理/问题管理
    2、DNS
    3、LB(负载均衡)
    4、CDN
    5、RPC框架
    6、名字发现/服务发现
    7、关系数据库
    8、NoSQL
    9、消息中间件
    10、代码管理
    11、持续集成
    12、日志系统
    13、监控系统
    14、配置系统
    15、发布系统/部署系统
    16、跳板机
    17、机器管理

    二、创业公司的选择
    1、选择合适的语言
    2、选择合适的组件和云服务商
    3、制定流程和规范
    4、自研和选型合适的辅助系统
    5、选择过程中需要思考的问题

    三、基于云的创业公司后台技术架构
    `

    回复

  12. 设计模式（45种）
    https://github.com/guanguans/notes/blob/master/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%EF%BC%8845%E7%A7%8D%EF%BC%89.md
    `
    设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。
    设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理地运用设计模式可以完美地解决很多问题，每种模式在现实中都有相应的原理来与之对应，每种模式都描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是设计模式能被广泛应用的原因。

    设计模式的类型
    共有 23 种设计模式。这些模式可以分为三大类：
    一、创建型模式（Creational Patterns）- 这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。
    二、结构型模式（Structural Patterns）- 这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。
    三、行为型模式（Behavioral Patterns）- 这些设计模式特别关注对象之间的通信。

    设计模式的六大原则
    1、开闭原则（Open Close Principle）
    开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。

    2、里氏代换原则（Liskov Substitution Principle）
    里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

    3、依赖倒转原则（Dependence Inversion Principle）
    这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。

    4、接口隔离原则（Interface Segregation Principle）
    这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。

    5、迪米特法则，又称最少知道原则（Demeter Principle）
    最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。

    6、合成复用原则（Composite Reuse Principle）
    合成复用原则是指：尽量使用合成 / 聚合的方式，而不是使用继承。
    `

    回复

  14. 初学软件设计模式应该读哪本书？
    https://www.zhihu.com/question/19679933
    `
    总结：我的推荐列表如下：
    入门（《Head First设计模式》/《设计模式》（刘伟）+《设计模式实训教程》（刘伟））→进阶（《研磨设计模式》/《设计模式之禅》）→应用（《设计模式:基于C#的工程化实现及扩展》）→理论提高（GOF《设计模式》）
    `

    图解设计模式
    https://book.douban.com/subject/26933281/
    http://tracefact.net/reading/067.html

    回复

  15. Golang 设计模式
    https://github.com/sevenelevenlee/go-patterns
    `
    前言
    一切设计模式都是灵活应用struct的组合模式，以及go隐形继承接口的特性
    go中的interface就是一些方法装饰, 而struct并不依赖于接口

    设计模式类型

    # 创建模式
    建造者模式(Builder Pattern) – 将一个复杂对象的构建与它的表示分离, 使得同样的构建过程可以创建不同的表示
    工厂方法模式(Factory Method) – 使一个类的实例化延迟到其子类, 定义一个用于创建对象的接口, 让子类决定将哪一个类实例化
    对象池模式(Object Pool) – 根据需求将预测的对象保存到channel中， 用于对象的生成成本大于维持成本
    单例模式(singleton) – 单例模式是最简单的设计模式之一, 保证一个类仅有一个实例, 并提供一个全局的访问接口
    生成器模式(Generator) – 生成器模式可以允许使用者在生成要使用的下一个值时与生成器并行运行
    抽象工厂模式(Abstract Factory) – 提供一个创建一系列相关或相互依赖对象的接口, 而无需指定它们具体的类
    原型模式(Prototype Pattern) – 复制一个已存在的实例

    # 结构模式
    装饰模式(Decorator Pattern) – 装饰模式使用对象组合的方式动态改变或增加对象行为， 在原对象的基础上增加功能
    代理模式(Proxy Pattern) – 代理模式用于延迟处理操作或者在进行实际操作前后对真实对象进行其它处理。
    适配器模式(Adapter Pattern) – 将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作
    组合模式(Composite) – 组合模式有助于表达数据结构, 将对象组合成树形结构以表示”部分-整体”的层次结构, 常用于树状的结构
    享元模式(Flyweight Pattern) – 把多个实例对象共同需要的数据，独立出一个享元，从而减少对象数量和节省内存
    外观模式(Facade Pattern) – 外观模式在客户端和现有系统之间加入一个外观对象, 为子系统提供一个统一的接入接口, 类似与委托
    桥接模式(Bridge Pattern) – 桥接模式分离抽象部分和实现部分，使得两部分可以独立扩展

    # 行为模式
    观察者模式(Observer) – 定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动刷新
    策略模式(Strategy) – 定义一系列算法，让这些算法在运行时可以互换，使得分离算法，符合开闭原则
    状态模式(State Pattern) – 用于系统中复杂对象的状态转换以及不同状态下行为的封装问题
    访问者模式(Visitor Pattern) – 访问者模式是将对象的数据和操作分离
    模板方法模式(Template Method Pattern) – 模版方法使用匿名组合的继承机制, 将通用的方法和属性放在父类中, 具体的实现放在子类中延迟执行
    备忘录模式(Memento Pattern) – 备忘录模式捕获一个对象的内部状态，并在对象之外保存这个状态
    中介模式(Mediator Pattern) – 中介者模式用一个中介对象来封装一系列对象交互，将多对多关联转换成一对多，构成星状结构
    迭代器模式(Iterator Pattern) – 可以配合访问者模式，将不同的数据结构，使用迭代器遍历
    解释器模式(Interpreter Pattern) – 解释器模式实现一个表达式接口，该接口解释一个特定的上下文。通常用于SQL解析和符号处理引擎
    命令模式(Command Pattern) – 命令模式是一种数据驱动模式，将请求封装成一个对象，从而可以用不同的请求对客户进行参数化，实现调用者和接收者的解藕
    责任链模式(Chain of Responsibility) – 责任链模式是将处理请求的多个对象连成一条链(类似队列)，每个对象都包含下一个对象的引用，请求沿着链传递，直到被处理

    # 同步模式(synchronization patterns)
    信号量模式(Semaphore) – 信号量是一种同步模式，对有限数量的资源同步互斥
    `

    回复

  16. 业务复杂=if else？刚来的大神竟然用策略+工厂彻底干掉了他们！
    https://mp.weixin.qq.com/s/RG-h7r69JyKUlBZylJJIFQ
    `
    对于业务开发来说，业务逻辑的复杂是必然的，随着业务发展，需求只会越来越复杂，为了考虑到各种各样的情况，代码中不可避免的会出现很多if-else。
    一旦代码中if-else过多，就会大大的影响其可读性和可维护性。

    其实，if-else是有办法可以消除掉的，其中比较典型的并且使用广泛的就是借助策略模式和工厂模式，准确的说是利用这两个设计模式的思想，彻底消灭代码中的if-else。

    本文，就结合这两种设计模式，介绍如何消除if-else，并且，还会介绍如何和Spring框架结合，这样读者看完本文之后就可以立即应用到自己的项目中。
    `

    回复

  17. 设计模式在外卖营销业务中的实践
    https://mp.weixin.qq.com/s/9gDGQhzRAL3pj35VAinZbQ
    `
    业务策略多变导致需求多变，是业界很多技术团队面临的最具挑战的问题之一。那么如何设计一套易于扩展和维护的营销系统呢？

    今天的文章来自美团外卖营销技术团队，他们分享了从领域模型到代码工程之间的转化，从DDD引出了设计模式，并详细介绍了工厂方法模式、策略模式、责任链模式以及状态模式这四种模式在美团营销业务中的具体实现，将理论与实践进行了一次深度结合。

    # 面向对象的设计模式有七大基本原则：
    * 开闭原则（Open Closed Principle，OCP）
    * 单一职责原则（Single Responsibility Principle, SRP）
    * 里氏代换原则（Liskov Substitution Principle，LSP）
    * 依赖倒转原则（Dependency Inversion Principle，DIP）
    * 接口隔离原则（Interface Segregation Principle，ISP）
    * 合成/聚合复用原则（Composite/Aggregate Reuse Principle，CARP）
    * 最少知识原则（Least Knowledge Principle，LKP）或者迪米特法则（Law of Demeter，LOD）

    简单理解就是：开闭原则是总纲，它指导我们要对扩展开放，对修改关闭；单一职责原则指导我们实现类要职责单一；里氏替换原则指导我们不要破坏继承体系；依赖倒置原则指导我们要面向接口编程；接口隔离原则指导我们在设计接口的时候要精简单一；迪米特法则指导我们要降低耦合。

    设计模式就是通过这七个原则，来指导我们如何做一个好的设计。但是设计模式不是一套“奇技淫巧”，它是一套方法论，一种高内聚、低耦合的设计思想。我们可以在此基础上自由的发挥，甚至设计出自己的一套设计模式。

    # 总结

    本文从营销业务出发，介绍了领域模型到代码工程之间的转化，从DDD引出了设计模式，详细介绍了工厂方法模式、策略模式、责任链模式以及状态模式这四种模式在营销业务中的具体实现。

    除了这四种模式以外，我们的代码工程中还大量使用了代理模式、单例模式、适配器模式等等，例如在我们对DDD防腐层的实现就使用了适配器模式，通过适配器模式屏蔽了业务逻辑与第三方服务的交互。因篇幅原因，这里不再进行过多的阐述。
    `

    回复

  18. 编程是一种思想，而不是敲代码
    https://mp.weixin.qq.com/s/IIGQj0q_FSRNT5jTTkMjEw
    `
    编程是一个先思考再编码的过程，思考是优于编码技能的，在思考过程中我们会考虑代码的可重用性、可靠性、更容易被他人理解，这时就会使用到设计模式让代码编写工程化，这篇文章整理了设计模式的六大原则。

    # 单一职责原则（Single Responsibility Principle）

    # 接口隔离原则（Interface Segregation Principle）

    # 依赖倒置原则（Dependence Inversion Principle）

    # 里氏替换原则（Liskov Substitution Principle）

    # 迪米特法则（Law of Demeter）

    # 开闭原则（Open Closed Principle）

    单一职责原则告诉我们实现类要职责单一；
    接口隔离原则告诉我们在设计接口的时候要精简单一；
    依赖倒置原则告诉我们要面向接口编程；
    里氏替换原则告诉我们不要破坏继承体系；
    迪米特法则告诉我们要降低耦合；
    开闭原则是总纲，告诉我们要对扩展开放，对修改关闭。
    `

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注