浅析 VO、DTO、DO、PO 的概念、区别和用处！ 本篇文章主要讨论一下我们经常会用到的一些对象：VO、DTO、DO和PO。由于不同的项目和开发人员有不同的命名习惯，这里我首先对上述的概念进行一个简单描述，名字只是个标识，我们重点关注其概念：概念：VO（View Object）：视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。DTO（Data Transfer Object）：数据传输对象，这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但在这里，我泛指用于展示层与服务层之间的数据传输对象。DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。PO（Persistent Object）：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。模型：下面以一个时序图建立简单模型来描述上述对象在三层架构应用中的位置用户发出请求（可能是填写表单），表单的数据在展示层被匹配为VO。展示层把VO转换为服务层对应方法所要求的DTO，传送给服务层。服务层首先根据DTO的数据构造（或重建）一个DO，调用DO的业务方法完成具体业务。服务层把DO转换为持久层对应的PO（可以使用ORM工具，也可以不用），调用持久层的持久化方法，把PO传递给它，完成持久化操作。对于一个逆向操作，如读取数据，也是用类似的方式转换和传递，略。VO与DTO的区别大家可能会有个疑问（在笔者参与的项目中，很多程序员也有相同的疑惑）：既然DTO是展示层与服务层之间传递数据的对象，为什么还需要一个VO呢？对！对于绝大部分的应用场景来说，DTO和VO的属性值基本是一致的，而且他们通常都是POJO，因此没必要多此一举，但不要忘记这是实现层面的思维，对于设计层面来说，概念上还是应该存在VO和DTO，因为两者有着本质的区别，DTO代表服务层需要接收的数据和返回的数据，而VO代表展示层需要显示的数据。用一个例子来说明可能会比较容易理解：例如服务层有一个getUser的方法返回一个系统用户，其中有一个属性是gender(性别)，对于服务层来说，它只从语义上定义：1-男性，2-女性，0-未指定，而对于展示层来说，它可能需要用“帅哥”代表男性，用“美女”代表女性，用“秘密”代表未指定。说到这里，可能你还会反驳，在服务层直接就返回“帅哥美女”不就行了吗？对于大部分应用来说，这不是问题，但设想一下，如果需求允许客户可以定制风格，而不同风格对于“性别”的表现方式不一样，又或者这个服务同时供多个客户端使用（不同门户），而不同的客户端对于表现层的要求有所不同，那么，问题就来了。再者，回到设计层面上分析，从职责单一原则来看，服务层只负责业务，与具体的表现形式无关，因此，它返回的DTO，不应该出现与表现形式的耦合。理论归理论，这到底还是分析设计层面的思维，是否在实现层面必须这样做呢？一刀切的做法往往会得不偿失，下面我马上会分析应用中如何做出正确的选择。更多关于 Java 的文章，我整理成了 PDF ,关注微信公众号 Java后端 回复 666 下载。VO与DTO的应用上面只是用了一个简单的例子来说明VO与DTO在概念上的区别，本节将会告诉你如何在应用中做出正确的选择。在以下才场景中，我们可以考虑把VO与DTO二合为一（注意：是实现层面）：需求非常清晰稳定，而且客户端很明确只有一个的时候，没有必要把VO和DTO区分开来，这时候VO可以退隐，用一个DTO即可，为什么是VO退隐而不是DTO？回到设计层面，服务层的职责依然不应该与展示层耦合，所以，对于前面的例子，你很容易理解，DTO对于“性别”来说，依然不能用“帅哥美女”，这个转换应该依赖于页面的脚本（如JavaScript）或其他机制（JSTL、EL、CSS）即使客户端可以进行定制，或者存在多个不同的客户端，如果客户端能够用某种技术（脚本或其他机制）实现转换，同样可以让VO退隐以下场景需要优先考虑VO、DTO并存：上述场景的反面场景因为某种技术原因，比如某个框架（如Flex）提供自动把POJO转换为UI中某些Field时，可以考虑在实现层面定义出VO，这个权衡完全取决于使用框架的自动转换能力带来的开发和维护效率提升与设计多一个VO所多做的事情带来的开发和维护效率的下降之间的比对。如果页面出现一个“大视图”，而组成这个大视图的所有数据需要调用多个服务，返回多个DTO来组装（当然，这同样可以通过服务层提供一次性返回一个大视图的DTO来取代，但在服务层提供一个这样的方法是否合适，需要在设计层面进行权衡）。DTO与DO的区别首先是概念上的区别，DTO是展示层和服务层之间的数据传输对象（可以认为是两者之间的协议），而DO是对现实世界各种业务角色的抽象，这就引出了两者在数据上的区别，例如UserInfo和User，对于一个getUser方法来说，本质上它永远不应该返回用户的密码，因此UserInfo至少比User少一个password的数据。而在领域驱动设计中，正如第一篇系列文章所说，DO不是简单的POJO，它具有领域业务逻辑。对于DTO和DO的命名规则，请参见：https://www.cnblogs.com/qixuejia/p/10789612.htmlDTO与DO的应用从上一节的例子中，细心的读者可能会发现问题：既然getUser方法返回的UserInfo不应该包含password，那么就不应该存在password这个属性定义，但如果同时有一个createUser的方法，传入的UserInfo需要包含用户的password，怎么办？在设计层面，展示层向服务层传递的DTO与服务层返回给展示层的DTO在概念上是不同的，但在实现层面，我们通常很少会这样做（定义两个UserInfo，甚至更多），因为这样做并不见得很明智，我们完全可以设计一个完全兼容的DTO，在服务层接收数据的时候，不该由展示层设置的属性（如订单的总价应该由其单价、数量、折扣等决定），无论展示层是否设置，服务层都一概忽略，而在服务层返回数据时，不该返回的数据（如用户密码），就不设置对应的属性。对于DO来说，还有一点需要说明：为什么不在服务层中直接返回DO呢？这样可以省去DTO的编码和转换工作，原因如下：两者在本质上的区别可能导致彼此并不一一对应，一个DTO可能对应多个DO，反之亦然，甚至两者存在多对多的关系。DO具有一些不应该让展示层知道的数据DO具有业务方法，如果直接把DO传递给展示层，展示层的代码就可以绕过服务层直接调用它不应该访问的操作，对于基于AOP拦截服务层来进行访问控制的机制来说，这问题尤为突出，而在展示层调用DO的业务方法也会因为事务的问题，让事务难以控制。对于某些ORM框架（如Hibernate）来说，通常会使用“延迟加载”技术，如果直接把DO暴露给展示层，对于大部分情况，展示层不在事务范围之内（Open session in view在大部分情况下不是一种值得推崇的设计），如果其尝试在Session关闭的情况下获取一个未加载的关联对象，会出现运行时异常（对于Hibernate来说，就是LazyInitiliaztionException）。从设计层面来说，展示层依赖于服务层，服务层依赖于领域层，如果把DO暴露出去，就会导致展示层直接依赖于领域层，这虽然依然是单向依赖，但这种跨层依赖会导致不必要的耦合。对于DTO来说，也有一点必须进行说明，就是DTO应该是一个“扁平的二维对象”，举个例子来说明：如果User会关联若干个其他实体（例如Address、Account、Region等），那么getUser()返回的UserInfo，是否就需要把其关联的对象的DTO都一并返回呢？如果这样的话，必然导致数据传输量的大增，对于分布式应用来说，由于涉及数据在网络上的传输、序列化和反序列化，这种设计更不可接受。如果getUser除了要返回User的基本信息外，还需要返回一个AccountId、AccountName、RegionId、RegionName，那么，请把这些属性定义到UserInfo中，把一个“立体”的对象树“压扁”成一个“扁平的二维对象”，笔者目前参与的项目是一个分布式系统，该系统不管三七二十一，把一个对象的所有关联对象都转换为相同结构的DTO对象树并返回，导致性能非常的慢。DO与PO的区别DO和PO在绝大部分情况下是一一对应的，PO是只含有get/set方法的POJO，但某些场景还是能反映出两者在概念上存在本质的区别：DO在某些场景下不需要进行显式的持久化，例如利用策略模式设计的商品折扣策略，会衍生出折扣策略的接口和不同折扣策略实现类，这些折扣策略实现类可以算是DO，但它们只驻留在静态内存，不需要持久化到持久层，因此，这类DO是不存在对应的PO的。同样的道理，某些场景下，PO也没有对应的DO，例如老师Teacher和学生Student存在多对多的关系，在关系数据库中，这种关系需要表现为一个中间表，也就对应有一个TeacherAndStudentPO的PO，但这个PO在业务领域没有任何现实的意义，它完全不能与任何DO对应上。这里要特别声明，并不是所有多对多关系都没有业务含义，这跟具体业务场景有关，例如：两个PO之间的关系会影响具体业务，并且这种关系存在多种类型，那么这种多对多关系也应该表现为一个DO，又如：“角色”与“资源”之间存在多对多关系，而这种关系很明显会表现为一个DO——“权限”。某些情况下，为了某种持久化策略或者性能的考虑，一个PO可能对应多个DO，反之亦然。例如客户Customer有其联系信息Contacts，这里是两个一对一关系的DO，但可能出于性能的考虑（极端情况，权作举例），为了减少数据库的连接查询操作，把Customer和Contacts两个DO数据合并到一张数据表中。反过来，如果一本图书Book，有一个属性是封面cover，但该属性是一副图片的二进制数据，而某些查询操作不希望把cover一并加载，从而减轻磁盘IO开销，同时假设ORM框架不支持属性级别的延迟加载，那么就需要考虑把cover独立到一张数据表中去，这样就形成一个DO对应对个PO的情况。PO的某些属性值对于DO没有任何意义，这些属性值可能是为了解决某些持久化策略而存在的数据，例如为了实现“乐观锁”，PO存在一个version的属性，这个version对于DO来说是没有任何业务意义的，它不应该在DO中存在。同理，DO中也可能存在不需要持久化的属性。DO与PO的应用由于ORM框架的功能非常强大而大行其道，而且JavaEE也推出了JPA规范，现在的业务应用开发，基本上不需要区分DO与PO，PO完全可以通过JPA，Hibernate Annotations/hbm隐藏在DO之中。虽然如此，但有些问题我们还必须注意：对于DO中不需要持久化的属性，需要通过ORM显式的声明，如：在JPA中，可以利用@Transient声明。对于PO中为了某种持久化策略而存在的属性，例如version，由于DO、PO合并了，必须在DO中声明，但由于这个属性对DO是没有任何业务意义的，需要让该属性对外隐藏起来，最常见的做法是把该属性的get/set方法私有化，甚至不提供get/set方法，但对于Hibernate来说，这需要特别注意，由于Hibernate从数据库读取数据转换为DO时，是利用反射机制先调用DO的空参数构造函数构造DO实例，然后再利用JavaBean的规范反射出set方法来为每个属性设值，如果不显式声明set方法，或把set方法设置为private，都会导致Hibernate无法初始化DO，从而出现运行时异常，可行的做法是把属性的set方法设置为protected。对于一个DO对应多个PO，或者一个PO对应多个DO的场景，以及属性级别的延迟加载，Hibernate都提供了很好的支持，请参考Hibnate的相关资料。到目前为止，相信大家都已经比较清晰的了解VO、DTO、DO、PO的概念、区别和实际应用了。通过上面的详细分析，我们还可以总结出一个原则：分析设计层面和实现层面完全是两个独立的层面，即使实现层面通过某种技术手段可以把两个完全独立的概念合二为一，在分析设计层面，我们仍然（至少在头脑中）需要把概念上独立的东西清晰的区分开来，这个原则对于做好分析设计非常重要（工具越先进，往往会让我们越麻木）。第一篇系列博文抛砖引玉，大唱领域驱动设计的优势，但其实领域驱动设计在现实环境中还是有种种的限制，需要选择性的使用，正如我在《田七的智慧》博文中提到，我们不能永远的理想化的去选择所谓“最好的设计”，在必要的情况下，我们还是要敢于放弃，因为最合适的设计才是最好的设计。

forEach 和 forEachOrdered在Java 8 Stream的区别 Stream.of("AAA","BBB","CCC").parallel().forEach(s->System.out.println("Output:"+s));Stream.of("AAA","BBB","CCC").parallel().forEachOrdered(s->System.out.println("Output:"+s);第二行输出的一直是： AAA BBB CCC 而第一种输出的情况不确定。应为是并行处理。 其实两者完成的功能类似，主要区别在并行处理上，forEach是并行处理的，forEachOrder是按顺序处理的，显然前者速度更快。parallel()采用并行化来处理stream流；当普通stream流时，即：Stream.of("AAA","BBB","CCC").forEach(s->System.out.println("Output:"+s));Stream.of("AAA","BBB","CCC").forEachOrdered(s->System.out.println("Output:"+s);forEach与forEachOrdered没有区别对于forEach ，当stream 为parallel的时候，是多个线程，并行处理的。因此输出的数据顺序不能保证。由于是并行处理，数据处理效率较高。 但是，对于操作共享变量的时候，需要注意安全问题，需要保证同步。比如下面例子：IntStream.range(0,1000).parallel().forEach(i->list.add(i));  System.out.println(list.size());有可能会报错：Exception in thread “main” java.lang.ArrayIndexOutOfBoundsException或者会出现，list.size 不为1000所以需要加同步锁来解决安全问题：IntStream.range(0,1000).parallel().forEach(i->{lock.lock();     try {             list.add(i);         }finally {                 lock.unlock();         } });  System.out.println(list.size());对于forEachOrdeed ，当stream 为parallel的时候，尽管是多个线程，并行处理的。但是还是会按照他source原有的顺序输出，，底层是通过happensbefore原则保证了它的内存可见性。（可以理解为相当于用volatile修饰了吧）所以下面的代码并不会报错：IntStream.range(0,1000).parallel().forEachOrdered(i->list.add(i)); System.out.println(list.size());

使用bat命令批量修改文件名中的一部分 大概3，400个文件需要改一下名字，把名字里面的1改成2，问我有没有方法。几种方案。1.网上找一下有没有这种批量改名的软件。2.用我刚学的Python给他开发一个软件。3.网上找一下有没有其他方法于是我开始构思，因为我下午还有事情要做，我很想用Python做个软件给他，可是凭我的水平，做好还要封装，而且我学习Python这么久还没有封装过程序，更何况我使用的是macOS系统，朋友使用的是Win10系统，没办法测试。算起来做好至少要3个小时，我可没有那么多时间。于是我继续搜索。看到网上有很多批量修改名字的软件。功能很强大，但是我不确定有没有我需要的功能，而且我没办法下载下来测试，因为电脑系统不同。在看了一眼他发给我的图片。继续网上搜索。这个时候BAT三个字映入了我的眼帘。网上评价说批量处理文件最适合的就是BAT了。于是我继续研究，我发现命令很简单，很多功能就一行就可以搞定。于是我帮着试试看的态度开始尝试。搞定！真的就一行命令。ren 1* 2*将上面这行命令保存成bat格式就可以了。然后放到要改名字的文件夹内，双击，成功！哈哈哈哈，被朋友夸奖了一番，满足了我的虚荣心。总结：做文件批量处理的时候BAT才是最简洁的命令语句。当然了只适合win系统，macOS系统是sh命令。又学会了一招。有空研究一下。

5分钟彻底理解Redis持久化 1|0Redis持久化1|1RDB快照在默认情况下，Redis将内存数据库快照保存到dump.rdb的二进制文件中。可以对Redis进行设置，让它在“N秒内数据集至少有N个改动”， 这一条件被满足时，自动保存一次数据集。比如说：让Redis满足“60秒内至少有1000个键被改动”这一个条件时，自动保存一次数据集。save 60 1000除了在配置文件中使用save关键字设置RDB快照，还可以在命令行中手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件。每次执行命令都会将所有redis内存快照保存到一个rdb文件里，并覆盖原有的rdb快照文件。save是同步命令，bgsave是异步命令，bgsave会从redis主进程fork出一个子进程专门用来生成rdb二进制文件。1|2AOF（append only file）快照功能并不是非常durable，如果redis因为某些原因而造成故障停机，那么服务器将丢失最近写入且未保存到快照中的那些数据。从1.1版本，redis增加了一种完全durable的方式：AOF持久化，将修改的每一条指令记录进appendonly.aof中。修改配置文件来打开aof功能：appendonly yes打开aof功能，每当redis执行一个改变数据集的命令时，这个命令就会追加到aof文件的末尾。这样的话，当redis重新启动时，程序就会通过执行aof文件中的命令来达到重建数据集的目的。可以配置redis多久才将命令持久化到磁盘一次。appendfsync always：每次有新命令追加到aof文件时就执行一个持久化，非常慢但是安全 appendfsync everysec：每秒执行一次持久化，足够快（和使用rdb持久化差不多）并且在故障时只会丢失1秒钟的数据 appendfsync no：从不持久化，将数据交给操作系统来处理。redis处理命令速度加快但是不安全。默认情况下 ，每秒执行一次fsync， 这种fsync策略可以兼顾安全性和速度。rdb和aof的区别：redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据，因为aof文件一般来说数据更安全一点。二、AOF重写aof文件里可能有太多“琐碎”指令，所以aof会定期根据内存的最新数据重新生成aof文件有两个配置可以控制aof自动重写的频率：auto-aof-rewrite-min-size 64mb： aof文件至少要达到64m才会触发制动重写，文件太小恢复速度本来就很快，重写的意义不大auto-aof-rewrite-percentage 100：aof文件上一次重写后文件大小增长了100%则再次触发重写当然aof还可以手动重写，进入redis客户端执行命令bgrewriteaof重写aof。触发aof重写时，redis会fork一个子进程去做，不会对redis正常命令处理有太多影响。2|0Redis 4.0混合持久化重启redis恢复数据集时，很少会使用rdb来恢复内存状态，因为会丢失大量数据。通常会使用aof日志恢复数据，但是重放aof日志性能相对rdb来说要慢很多，这样在redis实例很大的情况下，启动需要花费很长时间。Redis4.0为了解决这个问题，带来了新的持久化选项——混合持久化。aof-use-rdb-preamble yes混合持久化aof文件结构：如果开启了混合持久化，aof在重写时，不再是单纯将内存数据转换为RESP命令写入aof文件，而是将重写这一刻之前的内存做rdb快照处理，并且将rdb快照内容和增量的aof修改内存数据的命令存在一起，都写入新的aof文件，新的aof文件一开始不叫appendonly.aof，等到重写完成后，新的aof文件才会进行改名，原子的覆盖原有的aof文件，完成新旧两个aof文件的替换。于是在redis重启的时候，可以先加载rdb文件，然后再重放增量的aof日志就可以完全替代之前的aof全量文件重放，因此重启效率大幅得到提高。

【转】近期GitHub上有两款百度网盘不限速下载器的项目火了：BND&pan-light 近期GitHub上有两款百度网盘不限速下载器的项目火了，有了这两个下载器，百度网盘的会员都不用买了。堪称是百度网盘最大的敌人，同学们要抓紧时间下载，可能过几天这个项目就要被删库跑路了。这两个项目分别是BND（[https://github.com/b3log/baidu-netdisk-downloaderx]）pan-light（[https://github.com/peterq/pan-light]） BND是一款图形界面的百度网盘不限速下载器，支持Windows、Linux和Mac，分为BND1和BND2两个系列。BND1:小巧省资源支持 Windows、Linux 和 MacBND2:界面美观，操作便捷支持多任务并发下载仅支持 Windows 和 Mac而pan-light项目是一款不限速的百度网盘客户端，基于 Golang + Qt5 开发。本项意义在于探究 Golang 在图形界面客户端、Web 服务端、事件调度、WebSocket、P2P 长连接等方面的应用和实践。pan-light特性:利用golang轻量级协程, 高并发分段下载, 可通过调节并发数达到最佳下载速度; 下载进度状态数据持久化到磁盘, 实现软件重启后可断点续传;客户端本地实现简单代理, 突破百度防盗链, 将网盘视频喂给qt视频播放组件, 从而在线播放视频在线体验: 用户无需下载, 通过网页即可在线体验本软件部分功能; 该系统可应用于其他客户端产品的在线体验;在线体验原理: 闲置的个人pc, 通过 docker 开启若干个'虚拟机', 虚拟机内安装好了本软件以及vnc服务. 用户打开网页, 在服务端的调度下, 网页通过 web rtc 和闲置pc建立p2p连接. 闲置pc将会打通一条用户网页到docker内部'隧道'. 网页连接虚拟机vnc服务进行远程控制 

【转】layui时间显示 转自：https://www.cnblogs.com/silen0119/p/11388640.html第一次使用layui框架吧！记录layui踩到的坑！个人洁癖，不太喜欢显示时分秒。最后终于找到解决方案了！代码如下：{field: 'ctime',title: '时间',templet:"<div>{{layui.util.toDateString(d.ctime, 'yyyy-MM-dd')}}</div> " 参数改成你自己的即可！当layui显示错误日期如图：解决方法如下： {field: 'updatetime', title: '发布时间', templet: function(d) {return ''+layui.util.toDateString(d.updatetime*1000, 'yyyy-MM-dd')+'';} 参数改成你自己的即可！完美的解决了你的烦恼！ o(︶︿︶)o 唉，我明明是个后端......

如何使用Stream流操作将list中所有map的某个值拼接成字符串 list.stream().map(p->p.get("name")).collect(Collectors.joining(",")); package com.huifer.concurrence.issues; import java.util.ArrayList; import java.util.HashMap; import java.util.List; import java.util.Map; import java.util.stream.Collectors;public class C {     public static void main(String[] args) {         List<Map<String, String>> list = new ArrayList<>();         Map<String, String> m = new HashMap();         m.put("name", "樟树街");         Map<String, String> m1 = new HashMap();         m1.put("name", "樟树街1");         Map<String, String> m2 = new HashMap();         m2.put("name", "樟树街1");         list.add(m);         list.add(m2);         list.add(m1);                 String  s=  list.stream().map(p->p.get("name")).collect(Collectors.joining(","));         System.out.println(s);     } }Output:樟树街,樟树街1,樟树街2

win10定时关机怎么设置，教您win10设置定时关机操作方法 有时候我们会在清闲的时间里下载一些文件或视频，可是我们总不能傻傻的等着下载完成才关机，这给我们带来了许多麻烦。于是就得先设置一下定时关机，不过好多人不知道win10怎有时候我们会在清闲的时间里下载一些文件或视频，可是我们总不能傻傻的等着下载完成才关机，这给我们带来了许多麻烦。于是就得先设置一下定时关机，不过好多人不知道win10怎样设置定时关机？下面，小编就来教那些有需要的用户win10设置定时关机的操作方法。大家都知道手机有一个定时开关机的功能，那么电脑是不是也可以定时开关机呢？答案是肯定的，如果有需要的话，这样，就不用每次都要浪费时间了，那么win10怎么设置定时关机？下面，小编给大家分享win10设置定时关机的操作步骤了。win10怎么设置定时关机方法一：倒计时关机点击开始菜单中的运行选项，或者按Win+R快捷键打开运行窗口，输入“Shutdown -s -t 600”回车。其中600代表600秒，也就是10分钟后自动关机，大家可根据需求更改数字。方法二：定时关机若想实现定时关机，可使用命令“at 22:00 shutdown -s”，其中的22：00即为关机时间，也就是晚上10点自动关机，大家可根据需要自动关机的时间设置。不过第二种关机方法，系统不会有提示哦，如果我们中途又不想在设定的时间关机了，那么依旧打开运行窗口，将命令更改为“shutdown -a”，我们会看到桌面右下角弹出了取消关机的提示；取消自动关机：如果想取消自动关机指令，只要在运行窗口中输入“shutdown -a”回车即可。以上就是win10设置定时关机的操作方法了

基于centos6.5与WordPress搭建个人博客    文章转自：https://blog.csdn.net/weixin_36811328/article/details/81349516  很久之前的笔记，之前腾讯云的服务器不用了，所以搬移过来，本文主要记录了在centos上搭建WordPress的步奏。        所需工具：一台服务器，WordPress官方包主要步奏如下：购买服务器（这里使用的腾讯云服务器centos6.5，腾讯云学生认证后 1元/一个月）安装Apache与PHP安装MySQL安装WordPress一.安装Apache与PHP       购买服务器后我们得到一个服务器的IP地址与管理员账号密码，可以在网页的服务器管理界面直接登录服务器，不过这样不是很方便，通常使用secureCRT登录 securecrt下载链接 密码：av4y，地址为服务器IP地址，用管理员账号密码登录即可对服务器进行远程操作。二.安装Apache与PHP登录到服务器后便可以开始对服务器环境的配置了，这里安装环境使用适用于centos的yum命令安装RPM包，这种安装方法简单快捷。由于腾讯云服务器的配置问题导致yum命令不能正常使用，这里使用下面命令进行配置后即可正常使用。 wget -q http://mirrors.tencentyun.com/install/softinst.sh && chmod +x softinst.sh && ./softinst.sh安装Apache： yum install httpd安装PHP并使其支持MySQL： yum install php php-mysql php-gd php-imap php-ldap php-odbc php-pear php-xml php-xmlrpc php-mbstring php-mcrypt php-bcmath php-mhash启动Apache service httpd start 这时便可通过8080端口查看服务器是否正常安装 ip:8080三.安装MySQL安装MySQL并创建自己的数据库，同样使用yum命令进行安装，查看yum提供的MySQL数据库可下载版本： yum list | grep mysql安装MySQL以及MySQL-server，MySQL-devel： yum install -y mysql-server mysql mysql-deve 等待一会出现complete！即为安装完成。接下来启动MySQL服务： service mysqld start设置MySQL服务开机自动启动（这步可省略，腾讯云服务器默认自动启动）： chkconfig mysqld on设置数据库管理员密码： mysqladmin -u root password '你的密码'输入密码登录数据库： mysql -u root -p创建自己的数据库，在数据库登录状态输入： create database 你数据库的名字；输入quit；退出数据库这时可以进入数据库文件存放位置查看我们之前建立的数据库： cd /var/lib/mysqlmysql数据库是可以通过网络访问的，绑定的端口号是3306，通过查看linux监听的端口号可以看到我们建立的数据库： netstat -anp | more到这里数据库的建立便完成了，后面需要用到的有前面设置的数据库管理员账号密码及建立的数据库名字。四.安装WordPress进入服务器目录： cd /var/www/html下载WordPress安装包,这里下载的中文版的安装包，英语好的也可以下载英文原版压缩包： wget https://cn.wordpress.org/wordpress-4.5.3-zh_CN.tar.gz下载结束后用ls命令便能看到下载的压缩包解压安装包，filename指下载文件的名字，现在的版本是wordpress-4.5.3-zh_CN.tar.gz： tar -zxvf filename解压后ls可以看到解压后的wordpress文件夹 进入wordpress文件夹： cd wordpress将wp-config-simple.php重命名为wp-config.php: mv wp-config-simple.php wp-config.php用vim编辑器打开wp-config.php: vim wp-config.php照着图片修改内容： 保存退出，访问 http://云服务器IP/wordpress/ 便能看到著名的WordPress欢迎界面。 到这儿整个WordPress的安装过程便已完成，如果想要更随心所欲的修改自己的博客界面可以继续了解WordPress主题制作方面知识。主题制作相关资料提取密码：pota--------------------- 作者：Monky丶D 来源：CSDN 原文：https://blog.csdn.net/weixin_36811328/article/details/81349516 版权声明：本文为博主原创文章，转载请附上博文链接！

代码高亮测试 <!--?php echo 'hello jrotty!'; ?-->删除上边代码中的\https://jingyan.baidu.com/article/1e5468f97b3a79484961b7d7.html https://www.xcnte.com/archives/377/

欢迎使用 Typecho 如果您看到这篇文章,表示您的 blog 已经安装成功.