[Auth2.0 协议简介]
[OAuth 2.0的授权认证流程]
[OAuth 2.0 的核心概念]
[认证思路与流程]
[OAuth2.0 的四种模式] )
[1、授权码模式（authorization code）]
[2、隐式授权模式（Implicit Grant）]
[3、资源所有者密码凭证模式（Resource Owner Password Credentials Grant）]
[4、客户端凭证模式（Client Credentials Grant）]
关于应用系统用户身份管理需求，包括身份认证、权限授权、单点登录、联合身份认证等业务场景，业界有一堆的标准和规范，比如单点登录的CAS、Kerberos，第三方身份认证OpenID，第三方用户授权OAuth，联合身份认证和授权数据标准SAML等。每种技术有各自的应用场景，也存在交叉场景，想要把他们搞清楚，需要了解各种技术的工作原理和应用场景。今天就从其中一个技术开始，对OAuth2.0用户授权框架做一个简单介绍，想对框架全面了解的可以参考框架的标准RFC6749。
Oauth使用场景：
在OAuth之前，HTTP Basic Authentication, 即用户输入用户名&密码的形式进行验证, 这种形式是不安全的。OAuth的出现就是为了解决访问资源的安全性以及灵活性。举一个通俗的例子，用户把照片、视频、联系人数据存储在内容托管云服务R（Resource）中的Picture、Video、Contact三个模块中；用户使用在线照片打印服务P（Printer），用户需要让P服务读取R服务中的照片进行打印，但不想让P服务读取R服务中的其他数据。
传统方式下，用户只能向P服务提供R服务的用户名密码，P服务通过用户名密码登录R服务，读取照片，并且不能限制P服务读取的范围。
使用OAuth框架，通过以下授权流程，在不暴露用户密码的情况下，向P服务授予有限的操作S服务的权限，整体流程如下：
OAuth发展至今，共有三个版本，分别为：初始化版本OAuth1.0；漏洞修复版本OAuth 1.0a；不向后兼容的OAuth2.0版本。2.0版本主要是修复了前面版本的安全漏洞，对授权的流程进行了优化，提供了更丰富的使用场景，由于优化精简了授权的步骤，所以不能向后兼容。
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能。
项目地址：https://github.com/YunaiV/ruoyi-vue-pro
[OAuth 2.0的授权认证流程]
根据RFC描述，OAuth 2.0定义了4种服务角色，分别描述如下：
在认证和授权的过程中涉及的一些概念：
访问令牌（access token）
访问令牌是在用户授权许可下，授权服务器下发给客户端的一个授权凭证，该令牌所要表达的意思是“用户授予该APP在多少时间范围内允许访问哪些与自己相关的服务”，所以访问令牌主要在 时间范围 和 权限范围 两个维度进行控制，此外访问令牌对于客户端来说是非透明的，外在表现就是一个字符串，客户端无法知晓字符串背后所隐藏的用户信息，因此不用担心用户的登录凭证会因此而泄露。
刷新令牌（refresh token）
刷新令牌的作用在于更新访问令牌，访问令牌的有效期一般较短，这样可以保证在发生访问令牌泄露时，不至于造成太坏的影响，但是访问令牌有效期设置太短存在的副作用就是用户需要频繁授权，虽然可以通过一定的机制进行静默授权，但是频繁的调用授权接口，之于授权服务器也是一种压力，这种情况下就可以在下发访问令牌的同时下发一个刷新令牌，刷新令牌的有效期明显长于访问令牌，这样在访问令牌失效时，可以利用刷新令牌去授权服务器换取新的访问令牌，不过协议对于刷新令牌没有强制规定，是否需要该令牌是客户端可以自行选择。
回调地址（redirect uri）
OAuth2.0 是一类基于回调的授权协议，在授权码模式中，整个授权需要分为两步进行，第一步下发授权码，第二步根据第一步拿到的授权码请求授权服务器下发访问令牌。
OAuth 在第一步下发授权码时，是将授权码以参数的形式添加到回调地址后面，并以 302 跳转的形式进行下发，这样简化了客户端的操作，不需要再主动去触发一次请求，即可进入下一步流程，但若在客户端请求过程中修改了对应的回调地址，并指向其他的服务器，使客户端的授权码被盗用，或使用户被引导至恶意站点而被攻击，此外，还会使授权服务器变成“请求发送器”，以授权服务器为代理请求目标地址，消耗授权服务器性能的同时，对目标地址服务器产生 DDOS 攻击。
为了避免上述安全隐患，OAuth 协议强制要求客户端在注册时填写自己的回调地址，这个回调地址的目的是为了让回调请求能够到达客户端自己的服务器，从而可以走获取访问令牌的流程。客户端可以同时配置多个回调地址，并在请求授权时携带一个地址，服务器会验证客户端传递上来的回调地址是否与之前注册的回调地址相同，或者前者是后者集合的一个元素，只有在满足这一条件下才允许下发授权码，同时协议还要求两步请求客户端携带的回调地址必须一致，通过这些措施来保证回调过程能够正常达到客户端自己的服务器，并继续后面拿授权码换取访问令牌的流程。
权限范围（scope）
访问令牌自带过期时间，可以在时间维度上对授权进行控制，而在范围维度上，OAuth 引入了一个 scope 的概念。scope 可以看做是一个对象，包含一个权限的 ID，名称，以及描述信息等，比如“获取您的基本资料（头像、昵称）”。应该在接入账号服务时必须向第三方登录服务提供方申请响应的 scope，并在请求授权时指明该参数（否则表明获取该应用所允许的所有权限），这些权限在用户确认授权时，必须毫无保留的展示给用户，以让用户知道该APP需要获取用户的哪些数据或服务。
OAuth 在”客户端”与”服务提供商”之间，设置了一个 授权层（authorization layer）。”客户端”不能直接登录”服务提供商”，只能登录授权层，以此将用户与客户端区分开来。”客户端”登录授权层所用的令牌（token），与用户的密码不同，用户可以在登录的时候，指定授权层令牌的权限范围和有效期。”客户端”登录授权层以后，”服务提供商”根据令牌的权限范围和有效期，向”客户端”开放用户储存的资料。
官方 RFC 6749 文件中的 OAuth 2.0 流程图有点晦涩，优化了 一下：
[
上述中的第 2 步 是关键，即用户怎样才能给于客户端授权。有了这个授权以后，客户端就可以获取令牌，进而凭令牌获取资源。
基于微服务的思想，构建在 B2C 电商场景下的项目实战。核心技术栈，是 Spring Boot + Dubbo 。未来，会重构成 Spring Cloud Alibaba 。
项目地址：https://github.com/YunaiV/onemall
OAuth2.0 相对于 1.0 版本在授权模式上做了更多的细化，已定义的授权模式分为四种：授权码模式（Authorization Code Grant），隐式授权模式（Implicit Grant），资源所有者密码凭证模式（Resource Owner Password Credentials Grant），以及客户端凭证模式（Client Credentials Grant）。
授权码模式在整个授权流程上与 1.0 版本最贴近，但是整个流程还是要简化了许多，也是 OAuth2.0中最标准，应用最广泛的授权模式。这类授权模式非常适合于具备服务端的应用，当然现在大多数 APP 都有自己的服务端，所以大部分 APP 的 OAuth 授权都可以采取授权码模式，下图为授权码各个角色之间的交互时序（这里让用户直接参与其中，省略了用户代理）。
[
整个授权流程说明如下：
获取授权码
授权码是授权流程的一个中间临时凭证，是对用户确认授权这一操作的一个暂时性的证书，其生命周期一般较短，协议建议最大不要超过10分钟，在这一有效时间周期内，客户端可以凭借该暂时性证书去授权服务器换取访问令牌。
请求参数说明：
| 名称 | 是否必须 | 描述信息 |
|---|---|---|
| response_type | 必须 | 对于授权码模式 response_type=code |
| client_id | 必须 | 客户端ID，用于标识一个客户端，等同于appId，在注册应用时生成 |
| redirect_uri | 可选 | 授权回调地址，具体参见 2.2.3 小节 |
| scope | 可选 | 权限范围，用于对客户端的权限进行控制，如果客户端没有传递该参数，那么服务器则以该应用的所有权限代替 |
| state | 推荐 | 用于维持请求和回调过程中的状态，防止CSRF攻击，服务器不对该参数做任何处理，如果客户端携带了该参数，则服务器在响应时原封不动的返回 |
请求参数示例：
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https://client.example.com/cb HTTP/1.1
Host: server.example.com客户端携带上述参数请求授权服务器的令牌端点，授权服务器会验证客户端的身份以及相关参数，并在确认用户登录的前提下弹出确认授权页询问用户是否授权，如果用户同意授权，则会将授权码（code）和state信息（如果客户端传递了该参数）添加到回调地址后面，以 302 的形式下发。
成功响应参数说明：
| 名称 | 是否必须 | 描述信息 |
|---|---|---|
| code | 必须 | 授权码，授权码代表用户确认授权的暂时性凭证，只能使用一次，推荐最大生命周期不超过10分钟 |
| state | 可选 | 如果客户端传递了该参数，则必须原封不动返回 |
成功响应示例：
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz如果请求参数错误，或者服务器端响应错误，那么需要将错误信息添加在回调地址后面，以 302 形式下发（回调地址错误，或客户端标识无效除外）。
错误响应参数说明：
| 名称 | 是否必须 | 描述信息 |
|---|---|---|
| error | 必须 | 错误代码 |
| error_description | 可选 | 具备可读性的错误描述信息 |
| error_uri | 可选 | 错误描述信息页面地址 |
| state | 可选 | 如果客户端传递了该参数，则必须原封不动返回 |
错误响应示例：
HTTP/1.1 302 Found
Location: https://client.example.com/cb?error=access_denied&state=xyz下发访问令牌
授权服务器的授权端点在以 302 形式下发 code 之后，用户 User-Agent，比如浏览器，将携带对应的 code 回调请求用户指定的 redirect_url，这个地址应该能够保证请求打到应用服务器的对应接口，该接口可以由此拿到 code，并附加相应参数请求授权服务器的令牌端点，授权端点验证 code 和相关参数，验证通过则下发 access_token。
请求参数说明：
| 名称 | 是否必须 | 描述信息 |
|---|---|---|
| grant_type | 必须 | 对于授权码模式 grant_type=authorization_code |
| code | 必须 | 上一步骤获取的授权码 |
| redirect_uri | 必须 | 授权回调地址，具体参见 2.2.3 小节，如果上一步有设置，则必须相同 |
| client_id | 必须 | 客户端ID，用于标识一个客户端，等同于appId，在注册应用时生成 |
请求参数示例：
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https://client.example.com/cb授权服务器需要验证客户端的有效性，以及是否与之前请求授权码的客户端是同一个（请求授权时的信息可以记录在 code，或以 code 为 key 建立缓存），授权服务器还要保证code 处于生命周期内（推荐10分钟内有效），且只能被使用一次。授权服务器验证通过之后，生成 access_token，并选择性下发 refresh_token，OAuth2.0 协议明确了 token 的下发策略，对于生成策略没有做太多说明。
成功响应参数说明：
| 名称 | 是否必须 | 描述信息 |
|---|---|---|
| access_token | 必须 | 访问令牌 |
| token_type | 必须 | 访问令牌类型，比如 bearer，mac 等等 |
| expires_in | 推荐 | 访问令牌的生命周期，以秒为单位，表示令牌下发后多久时间过期，如果没有指定该项，则使用默认值 |
| refresh_token | 推荐 | 刷新令牌，选择性下发，参见 2.2.2 |
| scope | 可选 | 权限范围，如果最终下发的访问令牌对应的权限范围与实际应用指定的不一致，则必须在下发访问令牌时用该参数指定说明 |
成功响应示例：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "2YotnFZFEjr1zCsicMWpAA",
"token_type": "example",
"expires_in": 3600,
"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter": "example_value"
}错误响应参数说明：
| 名称 | 是否必须 | 描述信息 |
|---|---|---|
| error | 必须 | 错误代码 |
| error_description | 可选 | 具备可读性的错误描述信息 |
| error_uri | 可选 | 错误描述信息页面地址 |
错误响应示例：
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"error": "invalid_request"
}授权码授权流程分为两步走，将用户授权与下发 token 分开，这给授权带来了更多的灵活性，正常授权过程中必须经过用户登录这一步骤，在用户已登录的前提下，可以直接询问用户是否同意授权，但是在一些场景下，比如内部走 SSO 登录的应用集成了基于 OAuth 登录的第三方应用，这个时候在 OAuth 授权登录第三方应用时用户体验较好的流程是不需要用户再一次输入用户名和密码登录的，这就需要将外围APP 的登录态传递给该应用，但是这样是存在安全问题的，用户的登录态必须把握在走SSO 登录流程的应用中，这样的场景下授权码授权模式的两步走流程就可以满足在不交出用户登录态的情况下，无需再次登录即可授权。
内部应用可以拿着第三方应用的client_id 等信息代替第三方应用去请求获取 code，因为自己持有用户的登录态，所以过程中无需用户再次输入用户名和密码，拿到 code 之后将其交给第三方应用，第三方应用利用 code 和自己的 client_secret 信息去请求授权服务器下发 token，整个流程内部应用不需要交出自己持有的用户登录态，第三方应用也无需交出自己的 client_secret 信息，最终却能够实现在保护用户登录凭证的前提下无需再次登录即可完成整个授权流程。
令牌的刷新
为了防止客户端使用一个令牌无限次数使用，令牌一般会有过期时间限制，当快要到期时，需要重新获取令牌，如果再重新走授权码的授权流程，对用户体验非常不好，于是OAuth2.0 允许用户自动更新令牌。
具体方法是，B 网站颁发令牌的时候，一次性颁发两个令牌，一个用于获取数据，另一个用于获取新的令牌（refresh token 字段）。令牌到期前，用户使用 refresh token 发一个请求，去更新令牌。
https://b.com/oauth/token?grant_type=refresh_token&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_token=REFRESH_TOKEN
上面 URL 中：
B 网站验证通过以后，就会颁发新的令牌。
注意：第三方应用服务器拿到刷新令牌必须存于服务器，通过后台进行重新获取新的令牌，以保障刷新令牌的保密性。
有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）”隐藏式”（implicit）。
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI --->| |
| User- | | Authorization |
| Agent -|----(B)-- User authenticates -->| Server |
| | | |
| |<---(C)--- Redirection URI ----<| |
| | with Access Token +---------------+
| | in Fragment
| | +---------------+
| |----(D)--- Redirection URI ---->| Web-Hosted |
| | without Fragment | Client |
| | | Resource |
| (F) |<---(E)------- Script ---------<| |
| | +---------------+
+-|--------+
| |
(A) (G) Access Token
| |
^ v
+---------+
| |
| Client |
| |
+---------+它的步骤如下：
下面是上面这些步骤所需要的参数。
A步骤 中，客户端发出的HTTP请求，包含以下参数：
GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.comC步骤 中，认证服务器回应客户端的URI，包含以下参数：
HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&token_type=example&expires_in=3600在上面的例子中，认证服务器用HTTP头信息的Location栏，指定浏览器重定向的网址。注意，在这个网址的Hash部分包含了令牌。
根据上面的D步骤，下一步浏览器会访问Location指定的网址，但是Hash部分不会发送。接下来的E步骤，服务提供商的资源服务器发送过来的代码，会提取出Hash中的令牌。
如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。该应用就使用你的密码，申请令牌，这种方式称为”密码式”（password）。
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+它的步骤如下：
B步骤中，客户端发出的HTTP请求，包含以下参数：
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=johndoe&password=A3ddj3w
C步骤中，认证服务器向客户端发送访问令牌，下面是一个例子。
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "2YotnFZFEjr1zCsicMWpAA",
"token_type": "example",
"expires_in": 3600,
"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter": "example_value"
}整个过程中，客户端不得保存用户的密码。
最后一种方式是凭证式（client credentials），适用于没有前端的命令行应用，即在命令行下请求令牌。
当客户端请求访问其控制下的受保护资源时，客户端只能使用其客户端凭据（或其他支持的身份验证方法）来请求访问令牌。或者其他资源拥有者之前与授权服务器安排好的资源拥有者（其方法不在本文的范围之内）。客户端凭据授予类型必须仅供机密客户端使用。
+---------+ +---------------+
| | | |
| |>--(A)- Client Authentication --->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+---------+ +---------------+它的步骤如下：
A步骤中，客户端发出的HTTP请求，包含以下参数：
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials认证服务器必须以某种方式，验证客户端身份。
B步骤中，认证服务器向客户端发送访问令牌。
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "2YotnFZFEjr1zCsicMWpAA",
"token_type": "example",
"expires_in": 3600,
"example_parameter": "example_value"
}参考链接：
本文由哈喽比特于2年以前收录，如有侵权请联系我们。
文章来源：https://mp.weixin.qq.com/s/L6GZovXmvY25O1Ihf4VKbQ
京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而，京东官方通过微博发言人发布的消息澄清了这些传言，称这些言论纯属虚假信息和蓄意捏造。
日前，据博主“@超能数码君老周”爆料，国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为Mate60系列手机。
据报道，荷兰半导体设备公司ASML正看到美国对华遏制政策的负面影响。阿斯麦（ASML）CEO彼得·温宁克在一档电视节目中分享了他对中国大陆问题以及该公司面临的出口管制和保护主义的看法。彼得曾在多个场合表达了他对出口管制以及中荷经济关系的担忧。
今年早些时候，抖音悄然上线了一款名为“青桃”的 App，Slogan 为“看见你的热爱”，根据应用介绍可知，“青桃”是一个属于年轻人的兴趣知识视频平台，由抖音官方出品的中长视频关联版本，整体风格有些类似B站。
日前，威马汽车首席数据官梅松林转发了一份“世界各国地区拥车率排行榜”，同时，他发文表示：中国汽车普及率低于非洲国家尼日利亚，每百户家庭仅17户有车。意大利世界排名第一，每十户中九户有车。
近日，一项新的研究发现，维生素 C 和 E 等抗氧化剂会激活一种机制，刺激癌症肿瘤中新血管的生长，帮助它们生长和扩散。
据媒体援引消息人士报道，苹果公司正在测试使用3D打印技术来生产其智能手表的钢质底盘。消息传出后，3D系统一度大涨超10%，不过截至周三收盘，该股涨幅回落至2%以内。
9月2日，坐拥千万粉丝的网红主播“秀才”账号被封禁，在社交媒体平台上引发热议。平台相关负责人表示，“秀才”账号违反平台相关规定，已封禁。据知情人士透露，秀才近期被举报存在违法行为，这可能是他被封禁的部分原因。据悉，“秀才”年龄39岁，是安徽省亳州市蒙城县人，抖音网红，粉丝数量超1200万。他曾被称为“中老年...
9月3日消息，亚马逊的一些股东，包括持有该公司股票的一家养老基金，日前对亚马逊、其创始人贝索斯和其董事会提起诉讼，指控他们在为 Project Kuiper 卫星星座项目购买发射服务时“违反了信义义务”。
据消息，为推广自家应用，苹果现推出了一个名为“Apps by Apple”的网站，展示了苹果为旗下产品（如 iPhone、iPad、Apple Watch、Mac 和 Apple TV）开发的各种应用程序。
特斯拉本周在美国大幅下调Model S和X售价，引发了该公司一些最坚定支持者的不满。知名特斯拉多头、未来基金（Future Fund）管理合伙人加里·布莱克发帖称，降价是一种“短期麻醉剂”，会让潜在客户等待进一步降价。
据外媒9月2日报道，荷兰半导体设备制造商阿斯麦称，尽管荷兰政府颁布的半导体设备出口管制新规9月正式生效，但该公司已获得在2023年底以前向中国运送受限制芯片制造机器的许可。
近日，根据美国证券交易委员会的文件显示，苹果卫星服务提供商 Globalstar 近期向马斯克旗下的 SpaceX 支付 6400 万美元（约 4.65 亿元人民币）。用于在 2023-2025 年期间，发射卫星，进一步扩展苹果 iPhone 系列的 SOS 卫星服务。
据报道，马斯克旗下社交平台𝕏（推特）日前调整了隐私政策，允许 𝕏 使用用户发布的信息来训练其人工智能（AI）模型。新的隐私政策将于 9 月 29 日生效。新政策规定，𝕏可能会使用所收集到的平台信息和公开可用的信息，来帮助训练 𝕏 的机器学习或人工智能模型。
9月2日，荣耀CEO赵明在采访中谈及华为手机回归时表示，替老同事们高兴，觉得手机行业，由于华为的回归，让竞争充满了更多的可能性和更多的魅力，对行业来说也是件好事。
《自然》30日发表的一篇论文报道了一个名为Swift的人工智能（AI）系统，该系统驾驶无人机的能力可在真实世界中一对一冠军赛里战胜人类对手。
近日，非营利组织纽约真菌学会（NYMS）发出警告，表示亚马逊为代表的电商平台上，充斥着各种AI生成的蘑菇觅食科普书籍，其中存在诸多错误。
社交媒体平台𝕏（原推特）新隐私政策提到：“在您同意的情况下，我们可能出于安全、安保和身份识别目的收集和使用您的生物识别信息。”
2023年德国柏林消费电子展上，各大企业都带来了最新的理念和产品，而高端化、本土化的中国产品正在不断吸引欧洲等国际市场的目光。
罗永浩日前在直播中吐槽苹果即将推出的 iPhone 新品，具体内容为：“以我对我‘子公司’的了解，我认为 iPhone 15 跟 iPhone 14 不会有什么区别的，除了序（列）号变了，这个‘不要脸’的东西，这个‘臭厨子’。
