10.使用Annotaion的时候需要有哪些配置，他的加载过程是怎么样的？

①我们知道注释本身是不会做任何事情的，它仅提供元数据信息。要使元数据信息真正起作用，必须让负责处理这些元数据的处理器工作起来，如AutowiredAnnotationBeanPostProcessor 和 CommonAnnotationBeanPostProcessor 就是处理这些注释元数据的处理器。但是直接在 Spring 配置文件中定义这些 Bean 显得比较笨拙。Spring 为我们提供了一种方便的注册这些 BeanPostProcessor 的方式，这就是 <context:annotation-config/>。

<context:annotationconfig/> 将隐式地向 Spring 容器注册 AutowiredAnnotationBeanPostProcessor、CommonAnnotationBeanPostProcessor、PersistenceAnnotationBeanPostProcessor 以及 equiredAnnotationBeanPostProcessor 这 4 个 BeanPostProcessor。

在配置文件中使用 context 命名空间之前，必须在 <beans> 元素中声明 context 命名空间。

②当使用注释直接注释类时，所有通过 <bean> 元素定义 Bean 的配置内容已经被移除，仅需要添加一行 <context:component-scan/> 配置就解决所有问题了——Spring XML 配置文件得到了极致的简化（当然配置元数据还是需要的，只不过以注释形式存在罢了）。<context:component-scan/> 的 base-package 属性指定了需要扫描的类包，类包及其递归子包中所有的类都会被处理。

值得注意的是 <context:component-scan/> 配置项不但启用了对类包进行扫描以实施注释驱动 Bean 定义的功能，同时还启用了注释驱动自动注入的功能（即还隐式地在内部注册了 AutowiredAnnotationBeanPostProcessor 和 CommonAnnotationBeanPostProcessor），因此当使用 <context:component-scan/> 后，就可以将 <context:annotation-config/> 移除了。

③当在xml文件中加入上述配置后，其在加载时就会将处理器加载进jvm，然后当我们打标签后，每个打了标签的类或字段就会在程序开始运行时被加载形成依赖注入，当需要的时候调用即可。

11.什么是Filter，什么是Interceptor,他们的区别是什么，和AOP又是什么关系？

①Filter也称之为过滤器，它是Servlet技术中最实用的技术，Web开发人员通过Filter技术，对web服务器管理的所有web资源：例如Jsp, Servlet, 静态图片文件或静态 html 文件等进行拦截，从而实现一些特殊的功能。例如实现URL级别的权限访问控制、过滤敏感词汇、压缩响应信息等一些高级功能。

它主要用于对用户请求进行预处理，也可以对HttpServletResponse进行后处理。使用Filter的完整流程：Filter对用户请求进行预处理，接着将请求交给Servlet进行处理并生成响应，最后Filter再对服务器响应进行后处理。

② springmvc 中的Interceptor 拦截器也是相当重要和相当有用的，它的主要作用是拦截用户的请求并进行相应的处理。比如通过它来进行权限验证，或者是来判断用户是否登陆。

拦截器可以让你在Action和result被执行之前或之后进行一些处理。同时，拦截器也可以让你将通用的代码模块化并作为可重用的类。其中Struts2中的很多特性都是由拦截器来完成的。拦截是AOP的一种实现策略。拦截器是动态拦截Action调用的对象。它提供了一种机制可以使开发者可以定义在一个action执行的前后执行的代码，也可以在一个action执行前阻止其执行。同时也是提供了一种可以提取action中可重用的部分的方式。比较显而易见的就是能够切实保障用户的财产信息安全，为有关部门提供权限或者职权领域的有效划分与约束。

③把整个项目的流程比作一条河，那么监听器的作用就是能够听到河流里的所有声音，过滤器就是能够过滤出其中的鱼，而拦截器则是拦截其中的部分鱼，并且作标记。所以当需要监听到项目中的一些信息，并且不需要对流程做更改时，用监听器；当需要过滤掉其中的部分信息，只留一部分时，就用过滤器；当需要对其流程进行更改，做相关的记录时用拦截器。

在实现顺序上，过滤器是在servlet之前，而拦截器是在servlet内部

在配置上，过滤器是在web.xml里面配置，拦截器则是在servlet内部配置

12.生成Json有几种方式，他们之间的好处和坏处分别是什么，为什么推荐使用JsonTaglib来处理Json？

①一般有三种方式来生成Json：

第一种，String创建；

第二种，Map方式创建；

第三种，Bean转化，最常见。

②和其它的json转换方式相比：

使用简单；

转换处理灵活；

代码可读性高；

13.一份规范的接口文档应该包括什么内容，衡量接口（API）设计好和坏的准则是什么？

①编写规范：

②判断一个API是否优秀，并不是简单地根据第一个版本给出判断的，而是要看随着时间的推移，该API是否还能存在，是否仍旧保持得不错。槽糕的API接口各种各样，但是好的API接口对于用户来说必须满足以下几个点：

• 易学习：有完善的文档及提供尽可能多的示例和可copy－paste的代码，像其他设计工作一样，你应该应用最小惊讶原则。
• 易使用：没有复杂的程序、复杂的细节，易于学习；灵活的API允许按字段排序、可自定义分页、 排序和筛选等。一个完整的API意味着被期望的功能都包含在内。
• 难误用：对详细的错误提示，有些经验的用户可以直接使用API而不需要阅读文档。

而对于开发人员来说，要求又是不一样的：

• 易阅读：代码的编写只需要一次一次，但是当调试或者修改的时候都需要对代码进行阅读。
• 易开发：个最小化的接口是使用尽可能少的类以及尽可能少的类成员。这样使得理解、记忆、调试以及改变API更容易。

如何做到以上几点，以下是一些总结：

a. 面向用例设计

如果一个API被广泛使用了，那么就不可能了解所有使用该API的用户。如果设计者希望能够设计出被广泛使用的API，那么必须站在用户的角度来理解如何设计API库，以及如何才能设计出这样的API库。

b.采用良好的设计思路

在设计过程中，如果能按照下面的方式来进行设计，会让这个API生命更长久

• 面向用例的设计，收集用户建议，把自己模拟成用户，保证API设计的易用和合理
• 保证后续的需求可以通过扩展的形式完成
• 第一版做尽量少的内容，由于新需求可以通过扩展的形式完成，因此尽量少做事情是抑制API设计错误的一个有效方案
• 对外提供清晰的API和文档规范，避免用户错误的使用API，尤其是避免API（见第一节）靠后级别的API被用户知晓与误用

除此之外，下面还列出了一些具体的设计方法：

• 方法优于属性
• 工厂方法优于构造函数
• 避免过多继承
• 避免由于优化或者复用代码影响API
• 面向接口编程
• 扩展参数应当是便利的
• 对组件进行合理定位，确定暴露多少接口
• 提供扩展点

c. 避免极端的意见

在设计API的时候，一定要避免任何极端的意见，尤其是以下几点：

• 必须漂亮（API不一定需要漂亮）
• API必须被正确地使用（用户很难理解如何正确的使用API，API的设计者要充分考虑API被误用的情况：如果一个API可能会被误用，那么它一定会被误用）
• 必须简单（我们总会面临复杂的需求，能两者兼顾的API是更好的API）
• 必须高性能（性能可以通过其他手段优化，不应该影响API的设计）
• 必须绝对兼容（尽管本文一直提到如何保证兼容，但是我们仍然要意识到，一些极少情况下会遇到的不兼容是可以容忍的）

d.有效的API评审

API设计完成以后，需要经过周密的设计评审，评审的重点如下：

• 用例驱动，评审前必须提供完善的使用用例，确保用例的合理性和完备性。
• 一致性，是否与系统中其他模块的接口风格一致，是否与对称接口的设计一致。
• 简单明了，API应该简单好理解，容易学习和使用的API才不容易被误用，给我们带来更多的麻烦。
• API尽可能少，如果一个API可以暴露也可以不暴露，那么就不要暴露他，等到用户真正有需求的时候再将它成为一个公开接口也不迟。
• 支持持续改进，API是否能够方便地通过扩展的方式增加功能和优化。

e. 提高API的可测试性

API需要是可测试的，测试不应依赖实现，测试充分的API，尤其是经过了严格的“兼容性整合测试”的API，更能保证在升级的过程中不出现兼容性问题。兼容性整合测试，是指一组测试用例集合，这组测试用例会站在使用者的立场上使用API。在API升级以后，再检测这组测试用例是否能完全符合预期的通过测试，尽可能的发现兼容性问题。

f. 保证API的向后兼容

对于每一个API的设计者来说，都渴望做到“向后兼容”，因为不管是现在的API用户，还是潜在的API用户，都只信任那些可兼容的API。但向后兼容有多个层次上的意义，而且不同层次的向后兼容，也意味着不同的重要性和复杂度。

g. 保持逐步改善

过去我们总希望能将现有的“不合理”的设计完全推翻，然后按照现在“美好”的思路，重新设计这个API，但是在一段时间以后，又会碰到一样的状况，需要再推翻一次。 如果我们没有有效的逐步改善的办法，依靠推翻现有设计，重新设计API只能让我们回到起点，然后重现之前的过程。 要有一套行之有效的持续改善的办法来在API兼容的同时，改善API使之更好。

h. 把握API的生命周期

每一个API都是有生命周期的，我们需要让API的生命周期更长，并且在API的生命周期结束时能让其平滑的消亡。

• 告诉用户我们是如何设计的，避免误用，提供指导，错误的使用往往是缩短API寿命的一大杀手
• 提供试用期，API不可能一开始就是稳定，经过试用的API才能有更强的生命力
• 为API分级：内部使用；二次开发使用；开发或试用中；稳定；弃用API。避免API被滥用的同时，我们可以通过调整API的级别，来扩大其影响力，也能更优雅的结束一个API的生命周期。

开发API的过程其实就是一个沟通交流的过程。沟通的双方就是API用户和API设计者。

i. 一些具体的实施方案

在一个API不可避免要消亡或者改变的时候，我们应该接受并且面对这个事实，下面列举了几种保证兼容性的前提下，对API进行调整的办法：

• 将API标记为弃用，重新建立一个新的API。如果一个API不可避免要被消亡，这是唯一的办法。
• 为其添加额外的参数或者参数选项来实现功能添加
• 将现有API拆成两部分，提供一个精简的核心API，过去的API通过封装核心API上实现。这通常用于解决用户需要一个代码精简的版本时。
• 在现有的API基础上进行封装，提供一个功能更丰富的包或者类

14.Http的Header里面包含哪些字段，每个字段都有哪些含义？

请求头部，紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信息

Host: 主机名
Use-Agent: 浏览器基本资料
Accept: 浏览器能够识别的响应类型
Accept-Language: 浏览器默认语言
Accept-Encoding: 浏览器能够识别的压缩方式
Referer: 来路页面，
Connecton：是否保持连接

Cache-Control：缓存控制

Cookie：Cookie是用来存储一些用户信息以便让服务器辨别用户身份的

If-Modified-Since：把浏览器端缓存页面的最后修改时间发送到服务器去，服务器会把这个时间与服务器上实际文件的最后修改时间进行对比。如果时间一致，那么返回304，客户端就直接使用本地缓存文件。如果时间不一致，就会返回200和新的文件内容。客户端接到之后，会丢弃旧文件，把新文件缓存起来，并显示在浏览器中.

If-None-Match：If-None-Match和ETag一起工作，工作原理是在HTTP Response中添加ETag信息。 当用户再次请求该资源时，将在HTTP Request 中加入If-None-Match信息(ETag的值)。如果服务器验证资源的ETag没有改变（该资源没有更新），将返回一个304状态告诉客户端使用本地缓存文件。否则将返回200状态和新的资源和Etag.  使用这样的机制将提高网站的性能

15.Content-type中的数据类型，在Spring MVC中都怎么接收数据？

①常见的媒体格式类型如下：

•     text/html ： HTML格式
•     text/plain ：纯文本格式      
  
•     text/xml ：  XML格式
•     image/gif ：gif图片格式    
  
•     image/jpeg ：jpg图片格式 
  
•     image/png：png图片格式

   以application开头的媒体格式类型：

•    application/xhtml+xml ：XHTML格式
•    application/xml     ： XML数据格式
•    application/atom+xml  ：Atom XML聚合格式    
  
•    application/json    ： JSON数据格式
•    application/pdf       ：pdf格式  
  
•    application/msword  ： Word文档格式
•    application/octet-stream ： 二进制流数据（如常见的文件下载）
•    application/x-www-form-urlencoded ： <form encType=””>中默认的encType，form表单数据被编码为key/value格式发送到服务器（表单默认的提交数据的格式）

   另外一种常见的媒体格式是上传文件之时使用的：

•     multipart/form-data ： 需要在表单中进行文件上传时，就需要使用该格式

 ②获取数据的方法

a.直接将参数写在controller相应的方法形参中，适用于get方法，不适用于post方法

b.通过HttpServletRequest接收，post方式和get方式都可以。

c.通过一个bean来接收，post方式和get方式都可以

d.通过@PathVariable获取路径中的参数

e.使用@ModelAttribute注解获取POST请求的FORM表单数据

f.用注解@RequestParam绑定请求参数到方法入参

16.Put请求在Linux下的Tomcat或者是Resin中会收不到数据，怎么解决这个问题，原因是什么？为什么本地使用Jetty的时候往往是正常的？

17.War包是什么，为什么WEB服务通常打出来的都是War包？除了War包，还有几种打包格式，他们之间的区别呢？

①war：Web application Archive，与jar基本相同，但它通常表示这是一个Java的Web应用程序的包，tomcat这种Servlet容器会认出war包并自动部署。

②war包只有一个，方便管理上传，在安全性上比多文件安全，而且会自动解压。

③常见包区别：

作用与区别

i.  jar：通常是开发时要引用通用(JAVA)类，打成包便于存放管理；

ii. war：是做好一个(web)应用后，通常是网站，打成包部署到容器中；

iii. ear： 企业级应用，实际上EAR包中包含WAR包和几个企业级项目的配置文件而已，一般服务器选择WebSphere等，都会使用EAR包。通常是EJB打成ear包。

18.maven常用的打包插件有哪些？有什么区别？如何使用 ？

①第一种：可执行jar与依赖分开，依赖在lib目录里，需要jar和lib目录在同级目录，
优点：jar文件很小  
缺点：需要放置lib文件夹在平级目录

1            <plugin>
 2                <groupId>org.apache.maven.plugins</groupId>
 3                <artifactId>maven-jar-plugin</artifactId>
 4                <version>2.6</version>
 5                <configuration>
 6                    <archive>
 7                        <manifest>
 8                            <addClasspath>true</addClasspath>
 9                            <classpathPrefix>lib/</classpathPrefix>
10                            <mainClass>com.xxx.xxxService</mainClass>
11                        </manifest>
12                    </archive>
13                </configuration>
14            </plugin>
15            <plugin>
16                <groupId>org.apache.maven.plugins</groupId>
17                <artifactId>maven-dependency-plugin</artifactId>
18                <version>2.10</version>
19                <executions>
20                    <execution>
21                        <id>copy-dependencies</id>
22                        <phase>package</phase>
23                        <goals>
24                            <goal>copy-dependencies</goal>
25                        </goals>
26                        <configuration>
27                            <outputDirectory>${project.build.directory}/lib</outputDirectory>
28                        </configuration>
29                    </execution>
30                </executions>
31            </plugin>

②第二种：把所有依赖打进同一个jar包里。
缺点：jar文件会比较大，同时该插件有个bug会缺失spring的xds文件，导致无法运行jar，同时如果同级目录还有其它可执行jar文件依赖可能会产生冲突 
优点：方便快捷，打包完直接就能运行。

1            <plugin>
 2                <artifactId>maven-assembly-plugin</artifactId>
 3                <configuration>
 4                    <descriptorRefs>
 5                        <descriptorRef>jar-with-dependencies</descriptorRef>
 6                    </descriptorRefs>
 7                    <archive>
 8                        <manifest>
 9                            <mainClass>com.xxx.xxxService</mainClass>
10                        </manifest>
11                    </archive>
12                </configuration>
13                <executions>
14                    <execution>
15                        <id>make-assembly</id>
16                        <phase>package</phase>
17                        <goals>
18                            <goal>single</goal>
19                        </goals>
20                    </execution>
21                </executions>
22            </plugin>

③第三种：所有依赖打到同一个jar文件里。
缺点：jar文件过大、如果同级目录有其它可执行jar，依赖可能会产生冲突
优点：不会有任何bug，直接打成可执行jar文件，最省事。

1            <plugin>
 2                <groupId>org.apache.maven.plugins</groupId>
 3                <artifactId>maven-shade-plugin</artifactId>
 4                <version>2.4.3</version>
 5                <executions>
 6                    <execution>
 7                        <phase>package</phase>
 8                        <goals>
 9                            <goal>shade</goal>
10                        </goals>
11                        <configuration>
12                            <filters>
13                                <filter>
14                                    <artifact>*:*</artifact>
15                                    <excludes>
16                                        <exclude>META-INF/*.SF</exclude>
17                                        <exclude>META-INF/*.DSA</exclude>
18                                        <exclude>META-INF/*.RSA</exclude>
19                                    </excludes>
20                                </filter>
21                            </filters>
22                            <transformers>
23                                <transformer
24                                        implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
25                                    <resource>META-INF/spring.handlers</resource>
26                                </transformer>
27                                <transformer
28                                        implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
29                                    <resource>META-INF/spring.schemas</resource>
30                                </transformer>
31                                <transformer
32                                        implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
33                                    <resource>META-INF/spring.tooling</resource>
34                                </transformer>
35                                <transformer
36                                    implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
37                                    <mainClass>com.xxx.xxxInvoke</mainClass>
38                                </transformer>
39                            </transformers>
40                            <minimizeJar>true</minimizeJar>
41                            <shadedArtifactAttached>true</shadedArtifactAttached>
42                        </configuration>
43                    </execution>
44                </executions>
45            </plugin>

19.jetty,resin,tomcat的差别在哪里，在线上服务应该选择哪一种WEB服务器？

①tomcat和resin比较

1.首先从速度上来说，resin的速度要比tomcat快3倍，当然了官方的测试报告是针对resin-2.x与tomcat4.x版本以前的了，测试报告地址: 
http://www.caucho.com/articles/jsp_benchmarks.xtp

2.resin的启动与关闭机制感觉要比tomcat好很多，首先，tomcat在windows下启动，双击完startup.bat后总要等几秒钟才会启动服务，并且关闭的时候也是一样的，有的时候甚至双击了shutdown.bat后startup.bat的窗口还总是在那好长时间，并且如果你哪一次不小心直接关闭了dos窗口而没有运行shutdown，那下一次肯定要出问题，在linux下启动速度还是很不错的，但如果启动错误报错真是很郁闷。而相反,resin的启动就十分人性化了，运行httpd后会出来个窗口，其中有start和stop，你可以随时方便的启动和关闭服务，并且速度也十分的快，并且如果你的配置文件如果有改动的话，启动程序会自动监测并自动重启的，这样在配置环境的时候就不需要像tomcat那样需要反复人工关闭再启动，这点tomcat真是差的很远。

3.tomcat的报错机制真是不敢恭维，对于一个老手来说还是可以接受的，但如果对于一个刚开始写程序的人来说无疑是个灾难，哪怕仅仅只是个小错误，tomcat都会用整页的篇幅来描述，如果时间长了还好，但新手肯定会望而生畏的，相反，resin的报错是十分简洁而明确的，可以让你一眼就可以看出程序错误的类型和位置，这点对于刚开始学习的人来说无疑是很有帮助的。

4.resin对于中文的支持要比tomcat好不少，各种编码和转码很多都是对tomcat设计的，因为在resin平台下根本就不需要，这点对于开发也是很重要的，特别要提的一点就是，用tomcat写的面页很多时候如果只在面页加上contentType="text/html; charset=gb2312"还是不能完成编码的还必须要加入一条看起来像是画蛇添足的一条语句request.setCharac 
terEncoding("gb2312")，这一点真实让人不能忍受。 
5.resin支持自动编译Servlet和Bean。 
6.tomcat还不支持j2ee，至少在5以前还是这样的。

②tomcat和jetty比较

相同点：

1. Tomcat和Jetty都是一种Servlet引擎，他们都支持标准的servlet规范和JavaEE的规范。

不同点：

1. 架构比较 
   Jetty的架构比Tomcat的更为简单 
   Jetty的架构是基于Handler来实现的，主要的扩展功能都可以用Handler来实现，扩展简单。 
   Tomcat的架构是基于容器设计的，进行扩展是需要了解Tomcat的整体设计结构，不易扩展。

2. 性能比较 
   Jetty和Tomcat性能方面差异不大 
   Jetty可以同时处理大量连接而且可以长时间保持连接，适合于web聊天应用等等。 
   Jetty的架构简单，因此作为服务器，Jetty可以按需加载组件，减少不需要的组件，减少了服务器内存开销，从而提高服务器性能。 
   Jetty默认采用NIO结束在处理I/O请求上更占优势，在处理静态资源时，性能较高

3. 少数非常繁忙;Tomcat适合处理少数非常繁忙的链接，也就是说链接生命周期短的话，Tomcat的总体性能更高。 
   Tomcat默认采用BIO处理I/O请求，在处理静态资源时，性能较差。

4. 其它比较 
   Jetty的应用更加快速，修改简单，对新的Servlet规范的支持较好。 
   Tomcat目前应用比较广泛，对JavaEE和Servlet的支持更加全面，很多特性会直接集成进来。

③Jetty更满足公有云的分布式环境的需求，而Tomcat更符合企业级环境，而如果开发实力够硬的话，英文ok，则resin会是一个更好的选择，因为这个容器文档不多，要靠自己。

20.jetty,resin,tomcat的常见配置有哪些，内存，端口，日志文件都怎么配置？

21.如果有多个WEB服务，都把WEB服务都配置在一个容器里，还是一个WEB配置一个容器，他们的差别是什么，你觉得哪种方式更好？

22.在Linux服务器上部署的时候，一般都要有哪些脚本，这些脚本该怎么编写？

①在Java开发项目时经常要把正在开发的项目发布到测试服务器中去测试，一般的话是要把项目先打成war包，然后把war包发布到服务器中，关闭服务器， 最后重新启动服务器，虽然这过程不是很繁琐，但如果是多个工程都要发布的时候，发布的过程就会比较繁琐，所以福音来了……

通过 编写shell 脚本来完成这些操作，只要执行一个shell脚本，项目就可以自动发布到服务器了，用起来还是比较方便的。

②

23.域名和端口号是怎么对应起来的？应该通过域名访问吗，从域名服务商到服务器的流程是怎么样的？

24.Nginx的作用是什么，在WEB服务前端配置Nginx的好处是什么，除了Nginx，还有别的反向代理服务器吗？

25.在Controller里应该怎么处理Service的异常，大段的Try Catch 会有什么坏处？

①从入口开始，controller层的方法对应的是某个url，面向的是应用人员，应该返回他们能读懂的信息，所以controller必须做异常处理，一般来说会有统一的异常处理方法； 

service层面向的是controller，service层中的某些方法，必须保证其事务，所以在service层进行事务控制是相当必要的，对于多条sql进行事务控制，如果某个sql执行失败，那么应当对已经执行的sql语句进行回滚； 

dao层更多是单一的sql语句，没有必要进行事务控制，因为事务开销并不便宜（官方原话）； 

基于以上三点，回头再思考关于异常的处理，一般情况应该把异常网上抛，一直抛到最终处理的那一层，所以对于dao层和service其实是没有必要进行try-catch的，直接往上抛异常就可以。 

与之对应的，是spring的事务配置，默认情况下，spring只对运行时异常进行回滚，如果在dao层处理了异常，那么需要进行额外的配置，spring才会对异常进行回滚，常用的配置是@Transactional(rollbackFor=Exception.class)

顺便提一个java知识点，关于try-catch-finally中，finally的作用，finally设计之初就是为了关闭资源，如果在finally中使用return语句，会覆盖try或者catch的返回值，最常见的就是覆盖异常，即便catch往上抛了异常，也会被覆盖，返回finally中return语句的返回值。所以如果想要抓住异常的话就不要在finally中有返回值。

②大段的try-catch会使程序变得冗杂，可读性降低，所以dao,service中要尽量避免使用try-catch,在controller中能用拦截器处理也要尽量使用拦截器处理，或者结合AOP来处理异常，这样可以使代码更简洁易读。

26.对Service返回的结果是否要判空，为什么？

①需要判空，否则在controller层调用此结果就会出现空指针异常从而导致发生错误，要try-catch是很耗费系统资源的，所以如果能直接使用判断的方法避免的话再好不过了。

27.对Service返回的结果是否要打日志，应该打什么样的日志，为什么？

①对service返回的结果可以在service中就打日志，这样可以帮助我们快速定位错误地点，因为当项目上线之后，远程的debug显然是很麻烦的，如果能够通过查看日志快速定位就再好不过了

②要打的日志需要记录错误发生的时间，地点，错误类型，这样可以帮助程序员快速排查纠正。

28.该怎么模拟假数据，为什么在真实项目中，我们通常都是先定义接口，再写假数据，再去写业务逻辑？

①可以使用mock.js来构建相应的假数据

②先定义接口是为了让后端能做好工作划分，再写假数据是为了能让前后端并行开发，最后写业务逻辑就能使得各个部分分工明确独立不相互依赖了。

29.PostMan是什么，为什么要使用他来测试接口，除了Postman，还有哪些工具可以测试？

①Postman是一款功能强大的网页调试与发送网页HTTP请求的Chrome插件。

②当开发人员需要调试一个网页是否运行正常，并不是简简单单地调试网页的HTML、CSS、脚本等信息是否运行正常，更加重要的是网页能够正确是处理各种HTTP请求，毕竟网页的HTTP请求是网站与用户之间进行交互的非常重要的一种方式，在动态网站中，用户的大部分数据都需要通过HTTP请求来与服务器进行交互。

Postman插件就充当着这种交互方式的“桥梁”，它可以利用Chrome插件的形式把各种模拟用户HTTP请求的数据发送到服务器，以便开发人员能够及时地作出正确的响应，或者是对产品发布之前的错误信息提前处理，进而保证产品上线之后的稳定性和安全性。

③还有dhc,fiddler等工具

30.在Linux服务器上，有哪些工具是可以测试接口的，怎么用Wget或者是Curl分别发送Rest的四种请求？

31.内网IP和外网IP的区别是什么，在服务器上测试接口是否被防火墙屏蔽的时候，该用内网IP检测，还是该用外网IP检测？

①外网IP是全世界唯一的IP地址，仅分配给一个网络设备。而内网IP是由路由器分配给每一部内部使用的IP地址，而内网的所有用户都是通过同一个外网IP地址进行上网的，而内网的IP地址每个人的都不一样，Internet上的用户也无法直接访问到内网用户。简单来说呢，外网IP就是标示了您在整个互联网上的地址，就相当于小区的地址，而内网IP呢，就是标识着您在局域网里面的地址，也就是小区内的几栋几楼几号房子。

②在服务器上测试接口属于调用远程接口，所以需要用外网IP检测，如果使用内网IP是检测不出来的。

32.端口是什么含义，怎么判断一个端口是否被占用了，如何判断一个端口是否被防火墙拦截，怎么用Telnet判断端口号是否打开？

33.WEB服务器通常要配置哪几个端口，如果一台服务器上有多个不同的WEB服务，该怎么规划端口的使用，修真院的端口分配是怎么样的？

34.C标签是什么，为什么要使用C标签，有哪些常见的指令？

①C标签就是JSTL （JSP Standard Tag Library ）标准标签库 

②JSP标准标签库（JSTL）是一个JSP标签集合，它封装了JSP应用的通用核心功能。

JSTL支持通用的、结构化的任务，比如迭代，条件判断，XML文档操作，国际化标签，SQL标签。 除了这些，它还提供了一个框架来使用集成JSTL的自定义标签。

JSTL的目标是为了简化JSP页面的设计。对于页面设计人员来说，使用脚本语言（默认值是JAVA语言）操作动态数据是比较困难的，而采用标签和表达式语言相对容易一些，JSTL的使用为页面设计人员和程序开发人员的分工协作提供了便利。

③JSTL 核心标签库(C标签)标签共有14个，功能上分为4类：