整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
会创建一个 SEO 友好的 URL 只需要几分钟，但学会之后的好处，远不只有一个。
一个 SEO 友好的 URL 要易于理解和记忆，能提高用户点击或分享的机会，也能提高网站的可见性；当你在 URL 中添加了关键词，还能帮助搜索引擎去了解该页面的主题，有利于搜索排名。
在《外贸独立站域名挑选指南【2023】 | 慢慢来数字营销》一文中，我们提到了 URL（uniform resource locator）与域名之间的关系，域名是URL的组成部分。在《外贸谷歌SEO入门：长文+思维导图 | 慢慢来数字营销》这篇文章里也简单介绍了站内SEO的 On-Page SEO 包含很多要素，其中一个就是 URL 。
来源：SERanking
SEO 友好的 URL 能帮助网页获得一个良好的排名。什么样算 SEO 友好的 URL 呢？其实很简单，就是对用户友好的，能提高用户体验的 URL 。
URL 真能有这么大的帮助吗？谷歌真的看重 URL 吗？
谷歌还是很在乎的，毕竟 SEO入门指南还专门给了 URL 一个板块：
既然这么重要，对用户友好的，能提高用户体验的 URL 怎么创建呢？
URL（uniform resource locator，统一资源定位符），是用于在互联网上定位资源的唯一标识符，指向特定网站、网页或文档，就是我们俗称的网页地址。
URL 由很多部分组成，一个简单的示例 URL 拆解如图：
来源：ahrefs
虽然创建 SEO 友好的 URL 很有必要，但不建议大家去对现有的 URL 进行大幅度的改动，我们应该专注于接下来每一个新的博客、新的网页的 URL。
1、slug 部分的优化
前文提到了 Slug 的重要性，作为 URL 里关键的一部分，也是包含该个网页内容关键词的地方。
虽然近几年也有一种说法：在 URL 里包含关键词对排名的影响并不大。谷歌的 John Mueller 多次对此进行声明：
那是不是在“URL 中包含关键词”是一个没必要去优化的因素呢？
首先，谷歌官方肯定了做好 URL 的优化是有用的，虽然是一个很小的因素，但是我们要做好这个细节只需要花几秒钟，毕竟 SEO 就是由无数个优秀的小细节组成的。
这点，谷歌的 Matt Cutts 在一个视频中也有提到：
在视频中，Matt Cutts 也提到了一个清晰简洁的 URL 对提高用户体验的重要性，视频里着重强调了用户体验。
其实，这也提醒我们，在优化 URL 的 Slug 部分时，简洁有重点（关键词）才是我们应该做的。
优化 Slug 可以从这几方面入手：
Slug 不要太长，其实也等同于 URL 不要设置得太长，越短的 URL ，谷歌搜索引擎更容易索引到网页的主题。Backlinko 做过一个实验发现， URL 越长，在谷歌上的排名越下降：
来源：Backlinko
来源：hubspot
2、选择一个好的域名和顶级域名（后缀）
域名、顶级域名（后缀）对于SEO的影响这一点我们在《外贸独立站域名挑选指南【2023】 | 慢慢来数字营销》一文中已经讲解的很详细，这里也不再赘述。
谷歌表示：如果你的网站是多区域网站，建议考虑使用一种便于对网站进行地理位置定位的网址结构。
3、HTTPS 协议
HTTP 和 HTTPS 的区别咱们之前也聊到过，这点可以着重看看这篇文章：《5分钟教你搞定HTTPS！（附免费SSL证书申请流程） | 慢慢来数字营销》：
来源：neilpatel 博客
而作为 URL 的一部分，HTTPS 也是谷歌衡量排名的一个因素：
4、子文件夹 > 子域名
外贸独立站不要使用子域名！
外贸独立站不要使用子域名！！
外贸独立站不要使用子域名！！！
重要的事情应该多说几遍。开头咱们就提到，子域名是位于主域名之外的，被认为是一个单独的网站；而子文件夹（相当于子目录）其实就等于是网站里的一个页面，是网站的一部分。举个例子：
子文件夹：mmldigi.com/blog/
子域名：blog.mmldigi.com
mmldigi.com/blog/是mmldigi.com 的一部分，但 blog.mmldigi.com 是独立于 mmldigi.com 之外的。这就意味着谷歌在对 mmldigi.com 这个主域进行排名的时候，是不会考虑 blog.mmldigi.com 上面的内容的，但 mmldigi.com/blog/ 就不会有这样的情况。
谷歌官方有个对外说法：
但现实的情况是，有很多从事 SEO 方面工作的人表示：呵呵！
GetCredo 的创始人 Jonn Doherty 曾在社交媒体上表示：
从事相关工作的 Craig Emerson 也专门做过研究，表示：
我只需将子域名改为子目录，就能从前列 100 名开外的某处（我知道我甚至没有进入前 200 名）跃升至 SERP 排名第 57 位。与我的网站相关的其他一切都保持不变。
当然，子文件夹（子目录）也并非是绝对的选择，比如一些大型的电子商务网站，也有因为技术原因而无法选择子文件夹的情况。
不过对于做外贸独立站的朋友们来讲，我们上千个独立站项目的切身经历得出来的结论就是：外贸独立站不要使用子域名！
我们曾经有个项目，客户因为考虑到公司的目标市场情况，坚持选择子域名，但结果就是，同等的资源倾斜上去，表现真的还不如 .www 。虽然后面网站问题顺利解决了，但是这期间的损失还是很可惜的。
还有一点是，选择子文件夹的话，大家要注意子文件夹的关键词不要跟 Slug 重复。重复的关键词没有必要且影响用户观感。
5、避免使用日期
这跟前面提到不要有数字很相似。避免使用日期有两个原因：
6、不要轻易修改 URL
这个其实很好解释：
URL 对于 SEO 很有帮助，但这并不代表我们只要搞定了 URL 就是做好了 SEO 的优化，SEO 优化涉及的内容很多，只有方方面面都做到细致，才能让网站有更好的排名。
明：原文版权属于 Google，原文以 CC BY 3.0 协议发布，原文中的代码部分以 Apache 2.0 协议发布。中文翻译部分并非官方文档，仅供参考。
PageSpeed Insights analyzes a page to see if it follows our recommendations for making a page render in under a second on a mobile network. Research has shown that any delay longer than a second will cause the user to interrupt their flow of thought, creating a poor experience. Our goal is to keep the user engaged with the page and deliver the optimal experience, regardless of device or type of network.
一个网页是否可以在移动环境下用不到一秒的时间完成渲染，是一项非常重要的性能指标。研究显示，任何超过一秒钟的延迟都将打断用户的思维顺流状态，带来较差的体验。我们的目标是不论在任何设备或网络条件下，都要维持用户在网页中的沉浸状态，提供更好的体验。
It is not easy to meet the one second time budget. Luckily for us, the whole page doesn’t have to render within this budget, instead, we must deliver and render the above the fold (ATF) content in under one second, which allows the user to begin interacting with the page as soon as possible. Then, while the user is interpreting the first page of content, the rest of the page can be delivered progressively in the background.
想要达到这个标准并不是那么容易。不过幸运的是，我们并不需要在这个时间指标内渲染出整个页面，而是要在一秒以内传输并渲染出“首屏内容”（ATF），让用户尽快与页面交互。接下来，当用户与首屏内容进行交互的同时，页面的剩余部分可以在后台持续加载完成。
（译注：原文中的“ATF”一词源自传统出版业，指的是报纸头版的中折线以上区域，这块黄金区域往往用来刊登最有吸引力的新闻。延伸到互联网领域，ATF 指的是页面中不需要滚动就可以看到的首屏内容。）
Adapting to high latency mobile networks
适应高延迟的移动网络
Meeting the one second ATF criteria on mobile devices poses unique challenges which are not present on other networks. Users may be accessing your site through a variety of different 2G, 3G, and 4G networks. Network latencies are significantly higher than a wired connection, and consume a significant portion of our 1000 ms budget to render the ATF content:
在移动设备上达到“首屏秒开”的准则，需要面对其它网络所遇不到的独特挑战。用户可能正通过 2G、3G 或 4G 等各种各样的网络来访问你的网站。移动网络的延迟要明显高于有线连接，并且将消耗我们“首屏秒开”预算中的一大部分：
3G is the dominant network type around the world, and while 4G deployments are in progress around the world, you should still expect that the majority of users will be accessing your page on a 3G network. For this reason, we have to assume that each network request will take, on average, 200 milliseconds.
3G 是全球范围内占据统治地位的移动网络，而 4G 网络正在普及之中，你需要明白你的主流用户仍然在使用 3G 网络来访问你的页面。基于这个原因，我们不得不假设平均每次网络请求将消耗 200 ms。
With that in mind, let’s now work backwards. If we look at a typical sequence of communication between a browser and a server, 600 ms of that time has already been used up by network overhead: a DNS lookup to resolve the hostname (e.g. google.com) to an IP address, a network roundtrip to perform the TCP handshake, and finally a full network roundtrip to send the HTTP request. This leaves us with just 400 ms!
明白了这一点之后，我们来倒推一下时间。如果我们来分析一下浏览器与服务器之间一次典型的通信过程，会发现 600 ms 的时间就已经被网络本身消耗掉了：一次 DNS 查询用于将主机名（比如 google.com）解析为 IP 地址，一次网络往返用于发起 TCP 握手，以及最后一次完整的网络往返用于发送 HTTP 请求。我们就只剩下 400 ms 了！
[Figure 1] Render a mobile page in 1 second
[图 1] 一秒渲染一个移动页面
600 ms mandatory 3G network overhead which you cannot do anything about
这 600 ms 是不可避免的 3G 网络消耗，你对此无能为力。
400 ms which you can optimize by updating your server and structuring your page appropriately (what the tool tries to help you with)
这 400 ms 是你可以优化的，只要你合理地更新你的服务器，并以适当的方式构建你的页面（这正是 PageSpeed Insights 这个工具可以帮到你的）。
Delivering the sub one second rendering experience
实现半秒渲染的体验
After subtracting the network latency, we are left with just 400 milliseconds in our budget, and there is still a lot of work to do: server must render the response, client-side application code must execute, and the browser must layout and render the content. With that in mind, the following criteria should help us stay within the budget:
在除去网络延迟之后，我们的预算只剩下区区 400 ms 了，但我们仍然还有大量的工作要做：服务器必须渲染出响应内容，客户端应用程序代码必须执行，而且浏览器必须完成内容的布局和渲染。了解了这些之后，下面这些准则将帮助我们控制住预算：
(1) Server must render the response (< 200 ms)
(1) 服务器必须在 200 ms 以内渲染出响应内容
Server response time is the time it takes for a server to return the initial HTML, factoring out the network transport time. Because we only have so little time, this time should be kept at a minimum - ideally within 200 milliseconds, and preferably even less!
服务器响应时间就是在除去网络传输时间之后，一台服务器首先返回 HTML 所花费的时间。因为我们剩下的时间实在太少了，这个时间应该控制在最低限度——理想情况下应该低于 200 ms，而且越少越好！
(2) Number of redirects should be minimized
(2) 重定向的次数应该减至最少
Additional HTTP redirects can add one or two extra network roundtrips (two if an extra DNS lookup is required), incurring hundreds of milliseconds of extra latency on 3G networks. For this reason, we strongly encourage webmasters to minimize the number, and ideally eliminate redirects entirely - this is especially important for the HTML document (avoid “m dot” redirects when possible).
额外的 HTTP 重定向会增加一次或两次额外的网络往返（如果需要再次查询 DNS 的话就是两次），这在 3G 网络上将导致几百毫秒的额外延迟。因此，我们强烈建议网站管理员们减少重定向的次数，而且最好完全消除重定向——这对 HTML 文档来说尤其重要（尽可能避免重定向到 “m.” 二级域名的行为）。
(3) Number of roundtrips to first render should be minimized
(3) 首次渲染所需的网络往返次数应该减至最少
Due to how TCP estimates the capacity of a connection (i.e. TCP Slow Start), a new TCP connection cannot immediately use the full available bandwidth between the client and the server. Because of this, the server can send up to 10 TCP packets on a new connection (~14KB) in first roundtrip, and then it must wait for client to acknowledge this data before it can grow its congestion window and proceed to deliver more data.
由于 TCP 在评估连接状况方面采用了一套特殊机制（参见 TCP 慢启动），一次全新的 TCP 连接无法立即用满客户端和服务器之间的全部有效带宽。在这种情况下，服务器在首次网络往返中，通过一个新连接（约 14kB）只能发送最多 10 个 TCP 包，接下来它必须等待客户端应答这些数据，然后才能增加它的拥塞窗口并继续发送更多数据。
Due to this TCP behavior, it is important to optimize your content to minimize the number of roundtrips required to deliver the necessary data to perform the first render of the page. Ideally, the ATF content should fit under 14KB - this allows the browser to paint the page after just one roundtrip. Also, it is important to note that the 10 packet (IW10) limit is a recent update to the TCP standard: you should ensure that your server is upgraded to latest version to take advantage of this change. Otherwise, the limit will likely be 3-4 packets!
考虑到 TCP 的这种行为，优化你的内容就显得十分重要。传输必要数据、完成页面首次渲染所需的网络往返次数应该减至最少。理想情况下，首屏内容应该小于 14KB——这样浏览器才能在一次网络往返之后就可以绘制页面。同时，还有一个关键点需要留意，10 个数据包上限（IW10）源自 TCP 标准的最近一次更新：你应该确保你的服务器软件已经升级到最新版本，以便从这次更新中获益。否则，这个上限将可能降到 3～4 个数据包。
(4) Avoid external blocking JavaScript and CSS in above-the-fold content
(4) 避免在首屏内容中出现外链的阻塞式 JavaScript 和 CSS
Before a browser can render a page to the user, it has to parse the page. If it encounters a non-async or blocking external script during parsing, it has to stop and download that resource. Each time it does that, it is adding a network round trip, which will delay the time to first render of the page.
浏览器必须先解析页面，然后才能向用户渲染这个页面。如果它在解析期间遇到一个非异步的或具有阻塞作用的外部脚本的话，它就不得不停下来，然后去下载这个资源。每次遇到这种情况，都会增加一次网络往返，这将延后页面的首次渲染时间。
As a result, the JavaScript and CSS needed to render the above the fold region should be inlined, and JavaScript or CSS needed to add additional functionality to the page should be loaded after the ATF content has been delivered.
结论就是，首屏渲染所需的 JavaScript 和 CSS 应该内嵌到页面中，而用于提供附加功能的 JavaScript 和 CSS 应该在首屏内容已经传输完成之后再加载。
(5) Reserve time for browser layout and rendering (200 ms)
(5) 为浏览器的布局和渲染工作预留时间 (200 ms)
The process of parsing the HTML, CSS, and executing JavaScript takes time and client resources! Depending on the speed of the mobile device, and the complexity of the page, this process can take hundreds of milliseconds. Our recommendation is to reserve 200 milliseconds for browser overhead.
解析 HTML 和 CSS、执行 JavaScript 的过程也将消耗时间和客户端资源！取决于移动设备的速度和页面的复杂度，这个过程将占用几百毫秒。我们的建议是预留 200 ms 作为浏览器的时间消耗。
(6) Optimize JavaScript execution and rendering time
(6) 优化 JavaScript 执行和渲染耗时
Complicated scripts and inefficient code can take tens and hundreds of milliseconds to execute - use built-in developer tools in the browser to profile and optimize your code. For a great introduction, take a look at our interactive course for Chrome Developer Tools.
执行复杂的脚本和低效的代码可能会耗费几十或上百毫秒——可以使用浏览器内建的开发者工具来收集概况、优化代码。如果你想深入这个话题，不妨看看我们的《Chrome 开发者工具交互教程》。
Note: The above is also not the complete list of all possible optimizations - it is a list of top mobile criteria to deliver a sub one second rendering time - and all other web performance best practicesshould be applied. Check out PageSpeed Insights for further advice and recommendations.
请注意：以上并未列举出所有可能的优化方案——只列出了一些移动端达成半秒渲染时间的基本准则——其它所有的网页性能最佳实践也应该运用起来。到 PageSpeed Insights 来看看，获取进一步的建议和推荐方案。
For a deep-dive on the above mobile criteria, also check out
如果需要深入探索上述移动端准则，请参阅：
FAQ
常见问题
How do 4G networks impact above mobile criteria?
4G 网络对上述移动端准则有何影响？
Lower roundtrip latencies are one of the key improvements in 4G networks. This will help enormously, by reducing the total network overhead time, which is currently over 50% of our one second budget on 3G networks. However, 3G is the dominant network type around the world, and will be for years to come - you have to optimize pages with 3G users in mind.
较低的网络往返延迟是 4G 网络的一处关键改良。减少所有的网络损耗时间对网页性能将有巨大帮助，而目前在 3G 网络上这些损耗就占用了我们一秒预算中的大半时间。不管怎样，3G 仍然是全球最主流的移动网络，并且在今后几年都将如此——我们在优化网页时不得不把 3G 用户放在心上。
I am using a JavaScript library, such as JQuery, any advice?
我正在使用一个 JavaScript 类库，比如 jQuery，有什么建议吗？
Many JavaScript libraries, such as JQuery, are used to enhance the page to add additional interactivity, animations, and other effects. However, many of these behaviors can be safely added after the ATF content is rendered. Investigate moving the execution and loading of such JavaScript until after the page is loaded.
大多数 JavaScript 类库，比如 jQuery，通常用来增强页面、提供附加的交互、动画和其它效果。但是，大多数这些行为可以安全地在首屏渲染之后再加入进来。研究一下是否可以把这些 JavaScript 的加载和执行推迟到页面加载之后。
I am using a JavaScript framework, to construct the page, any advice?
我在正使用一个 JavaScript 框架来渲染整个页面，有什么建议吗？
If the content of the page is constructed by client-side JavaScript, then you should investigate inlining the relevant JavaScript modules to avoid extra network roundtrips. Similarly, leveraging server-side rendering can significantly improve first page load performance: render JS templates on the server, inline the results into HTML, and then use client-side templating once the application is loaded.
如果页面内容是由客户端 JavaScript 来渲染的，那么你应该研究一下是否可以把相关的 JavaScript 模块都内嵌进来，以免产生额外的网络往返开销。同样，利用服务器端渲染可以显著地改善首次页面加载的性能：在服务器端渲染 JS 模板，并内嵌到 HTML 中，然后一旦应用程序加载完成就立即在客户端渲染模板。
SPDY and HTTP 2.0 both aim to reduce latency of page loads by making more efficient use of the underlying TCP connection (multiplexing, header compression, prioritization). Further, server push can further help improve performance by eliminating extra network latency. We encourage you to investigate adding SPDY support on your servers, and switching to HTTP 2.0 once the standard is ready.
SPDY 和 HTTP 2.0 协议的目标都是通过更有效地利用底层的 TCP 连接（多路复用、头压缩、优先化处理），来减少页面的加载延迟。而且服务器 push 通过消除额外的网络延迟，可以进一步促进性能的改善。我们建议你为服务器增加对 SPDY 协议的支持，并且当 HTTP 2.0 标准就绪之后就立即切换过去。
（译注：“Critical CSS” 是指首屏渲染所必需的最小化的 CSS 代码集合。）
In Chrome Developer Tools, open the Audits panel, and run a Web Page Performance report, in the generated report, look for Remove unused CSS rules. Or use any other third party tool, or script, to identify which CSS selectors are applied on each page.
在 Chrome 开发者工具中，打开审计（Audits）面板，然后运行一次网页性能（Web Page Performance）报告。在生成的报告中，试一下“删除未使用的 CSS 规则（Remove unused CSS rules）”。也可以使用其它第三方工具或脚本，来识别每个页面分别应用了哪些 CSS 选择符。
Absolutely. There are many commercial and open-source web performance optimization (WPO) products which can help you meet some or all of the criteria above. For open-source solutions, take a look at the PageSpeed optimization tools.
当然可以。有很多商业的或开源的网页性能优化（WPO）产品都可以帮你达成上述部分或全部准则。对于开源解决方案，不妨看看 PageSpeed 优化工具。
First, ensure that your server is running an up-to-date version of the operating system. In order to benefit from the increased initial TCP congestion window size (IW10), you will need Linux kernel 2.6.39+. For other operating systems, consult the documentation.
首先，确保你的服务器正在运行最新版的操作系统。为了从 TCP 初始拥塞窗口数量的增加（IW10）中获益，你需要 2.6.39+ 版本的 Linux 内核。对于其它操作系统，请查阅相关文档。
To optimize server response time, instrument your code, or use an application monitoring solution to identify your bottleneck - e.g., scripting runtime, database calls, RPC requests, rendering, etc. The goal is to render the HTML response within 200 milliseconds.
为了优化服务器的响应时间，请测评你的代码性能，或使用监控程序来发现性能瓶颈——比如脚本运行时、数据库调用、RPC 请求、渲染等等。最终目标就是在 200 ms 内渲染出 HTML 响应内容。
If you are using CSP, then you may need to update your default policy.
如果你正在使用 CSP，那么你可能需要更新你的默认策略。（译注：CSP 是一项用于防范 XSS 的安全性规范，具体参见 Content Security Policy - 维基百科。）
First, inline CSS attributes on HTML elements(e.g., <p style=...>) should be avoided where possible, as they often lead to unnecessary code duplication, and are blocked by default with CSP (disabled via “unsafe inline” on “style-src”). If you have inline JavaScript, then you will need to update the CSP policy with “unsafe-inline” to enable its execution. By default, CSP will block all inline script tags.
首先，尽可能避免在 HTML 元素中内联 CSS 属性（比如这样 <p style=...>），因为它们常常导致不必要的重复代码，而且默认会被 CSP 拦截（对 style-src 字段使用 unsafe-inline 指令可以禁用此类拦截）。如果你使用了内联的 JavaScript，那么你需要在 CSP 策略中使用 unsafe-inline 指令来令其执行。默认情况下，CSP 将拦截所有内联脚本标签。（译注：这里的“内联 JavaScript”包括多种形态的 HTML 内部的脚本代码，包括类似 <script>foo();</script> 这样的内嵌脚本标签、<a href="javascript：foo();"> 这样的伪协议 URL、以及 <a href="#" onclick="foo();"> 这样的事件处理属性。）
点赞+转发，让更多的人也能看到这篇内容（收藏不点赞，都是耍流氓-_-）
关注 ｛我｝，享受文章首发体验！
每周重点攻克一个前端技术难点。更多精彩前端内容私信 我 回复“教程”
原文链接：https://github.com/cssmagic/blog/issues/20
在推特上点赞支持香港暴徒的报道贴文，韩国男团Super Junior成员崔始源陷入全网热议。目前，他已经在微博上做出两次道歉，但是中国网友却更怒了……
两次道歉被质疑“微博专供”
26日中午，崔始源在微博上表示，“从未有过否认和改变香港是中国不可分割的一部分的想法和立场”。
其实，这已经是“点赞”事件后，崔始源在微博上做出的第二次道歉。
此前，在24日晚，崔始源就曾在微博上发表道歉声明，“我抱着希望早日平息止暴止乱的想法，表达我的关注”。
然而，这条微博被网友指责道歉内容模棱两可，而且将早日止暴止乱又写成了“早日平息止暴止乱”。
紧接着，他被中国粉丝要求退出组合、禁止前来中国发展，崔始源吧微博直接宣布关吧。
中国网友一波接一波的强硬态度，让崔始源意识到事情的严重性。
于是，在26日中午，崔始源发表了第二次道歉，为自己作为艺人辜负了众人给予的期待与信赖而感到自责与悲痛。
不过，连续两次道歉，并没有让中国网友就此买账。相反，大家发现，这两次道歉都只发布在微博上，而他的海外社交媒体账号没有发布任何有关道歉的内容。
他的推特账号上最新一条内容是24日发布的“为众人祈祷”↓↓
这次，中国网友更怒了！大家扎堆要求崔始源在各个海外社交媒体平台上做出道歉，而不是仅发布“微博专供道歉”。
推特点赞激怒中国网友
还炒上了外媒
整个事件的起因是崔始源在推特上点赞韩国媒体《朝鲜日报》对香港暴徒的报道。
据悉，该报道采访了攻击香港警察被制服的暴徒，后者高呼“因子弹而死，但信念长存”。
CD君查阅了崔始源的推特账号，发现他已经默默取消了对这篇贴文的点赞。
但是，有眼尖的网友发现，在微博上发完道歉声明后，崔始源将他的推特账号背景图设置为一个英文单词“principle”（原则），令人浮想联翩。
直到目前，崔始源的推特背景图都没有更改，也没有做出任何针对此事的道歉。
作为韩国早期备受瞩目的男团Super Junior的成员，崔始源曾在中国圈了一大波粉丝。尤其是在2015年一档综艺节目中，他和超模刘雯以“情侣”的形式参加活动，收获不少观众的喜爱。
如今，中国粉丝纷纷要求脱粉、微博关闭崔始源吧……
中国网友大规模脱粉的行为，甚至引发了外媒关注。
法新社11月26日报道称，因点赞有关香港的推特后，韩国明星的中国粉丝们“脱粉”了。
文章援引一位粉丝的话称，“不会原谅你，因为我的国家更重要。”
“(I) will not forgive you, because my country is more important,” wrote one.
报道称，粉丝们指责崔始源在道歉时没有诚意，批评他仅在微博而非其他平台上发表道歉。
Fans also accused Choi of not being sincere in his apology, and criticized him for posting it only to Weibo and not to other platforms.
《南华早报》也在报道中援引两位网友的话称，“你什么都不知道，为什么要‘点赞’？”“如果你真心道歉，为什么不发到脸书和照片墙（Ins）上？别以为中国粉丝都是傻子。”
“You don’t know anything at all. Why did you even ‘like’ it?” read one top-rated comment on Choi’s page on Weibo.
“If you are really sincere in your apology, why don’t you put a statement on Facebook and Instagram? Don’t think that Chinese fans are all fools,” wrote another.
令人感到讽刺的是，崔始源曾在某个综艺节目中曾谈到自己对于政治问题的看法，他认为“艺人和政治沾边，是一个危险的事。”
这次“以身试法”，恐怕他会对“危险”二字有更深刻的理解吧。
来源：中国日报新媒体
编辑：胡雨濛
部分内容参考：参考消息、观察者网
*请认真填写需求信息，我们会在24小时内与您取得联系。
