本文介绍了美团到家/站外投放团队在多场景建模技术方向上的探索与实践。基于外部投放的业务背景，本文提出了一种自适应的场景知识迁移和场景聚合技术，解决了在投放中面临外部海量流量带来的场景数量丰富、场景间差异大的问题，取得了明显的效果提升。希望能给大家带来一些启发或帮助。

1 引言

美团到家Demand-Side Platform（下文简称DSP）平台，主要负责在美团外部媒体上进行商品或者物料的推荐和投放，并不断优化转化效果。随着业务的不断发展与扩大，DSP对接的外部渠道越来越丰富、展示形式越来越多样，物料展示场景的差异性愈发明显（如开屏、插屏、信息流、弹窗等）。

例如，用户在午餐时间更容易点击【某推荐渠道下】【某App】【开屏展示位】的快餐类商家的物料而不是【信息流展示位】的啤酒烧烤类商家物料。场景间差异的背后本质上是用户意图和需求的差异，因此模型需要对越来越多的场景进行定制化建设，以适配不同场景下用户的个性化需求。

业界经典的Mixture-of-Experts架构（MoE，如MMoE、PLE、STAR^[1]等）能一定程度上适配不同场景下用户的个性化需求。这种架构将多个Experts的输出结果通过一个门控网络进行权重分配和组合，以得到最终的预测结果。早期，我们基于MoE架构提出了使用物料推荐渠道进行场景划分的多场景建模方案。然而，随着业务的不断壮大，场景间的差异越来越大、场景数量也越来越丰富，这版模型难以适应业务发展，不能很好地解决DSP背景下存在的以下两个问题：

在面对此类建模任务时，业界现有的方法是在不同场景间进行知识迁移。例如，SAML^[2]模型采用辅助网络来学习场景的共享知识并迁移至各场景的独有网络；ADIN^[3]和SASS^[4]模型使用门控单元以一种细粒度的方式来选择和融合全局信息到单场景信息中。然而，在DSP背景中复杂多变的流量背景下，场景差异性导致了场景数量的急剧增长，现有方法无法在巨量稀疏场景下有效。

因此，在本文中我们提出了DSP背景下的自适应场景建模方案（AdaScene, Adaptive Scenario Model），同时从知识迁移和场景聚合两个角度进行建模。AdaScene通过控制知识迁移的程度来最大化不同场景共性信息的利用，并使用稀疏专家聚合的方式利用门控网络自动选择专家组成场景表征，缓解了负迁移现象；同时，我们利用损失函数梯度指导场景聚合，将巨大的推荐场景空间约束到有限范围内，缓解了数据稀疏问题，并实现了自适应场景建模方案。

2 自适应场景建模

在本节开始前，我们先介绍多场景模型的建模方式。多场景模型采用输入层 Embedding + 混合专家（Mixture-of-Experts, MoE）的建模范式，其中输入信息包括了用户侧、商家侧以及场景上下文特征。多场景模型的损失由各场景的损失聚合而成，其损失函数形式如下：

其中，$K$为场景数量，$α_i$为各场景的损失权重值。

我们提出的AdaScene自适应场景模型主要包含以下2个部分：场景知识迁移（Knowledge Transfer）模块以及场景聚合（Scene Aggregation）模块，其模型结构如下图2所示。场景知识迁移模块自适应地控制不同场景间的知识共享程度，并通过稀疏专家网络自动选择 K 个专家构成自适应场景表征。场景聚合模块通过离线预先自动化衡量所有场景间损失函数梯度的相似度，继而通过最大化场景相似度来指导场景的聚合。

该模型结构的整体损失函数如以下公式所示：

其中，$\alpha_{k}$为每个场景组的损失函数所对应的系数，$G_k$为第$k$个场景组下的的场景数量，$G$为某种场景组的划分方式。

下面，我们分别介绍自适应场景知识迁移和场景聚合的建模方案。

2.1 自适应场景知识迁移

在多场景建模中，场景定义方式决定了场景专家的学习样本，很大程度上影响着模型对场景的拟合能力，但无论采用哪种场景定义方式，不同场景间用户分布都存在重叠，用户行为模式也会有相似性。

为提升不同场景间共性的捕捉能力，我们从场景特征和场景专家两个维度探索场景知识迁移的方法，在以物料推荐渠道×App×展示形态作为多场景建模Base模型的基础上，构建了如下图3所示的自适应场景知识迁移模型（Adaptive Knowledge Transfer Network, AKTN）。该模型建立了场景共享参数与私有参数的知识迁移桥梁，能够自适应地控制知识迁移的程度、缓解负迁移现象。

• 场景特征适配：通过Squeeze-and-Excitation Network^[5]构建场景适应层（Scene Adaption Layer），其结构可表示为$F_{SE}= FC( ReLU( FC(x)))$，其中$FC$表示全连接层，$ReLU$为激活函数。由于不同场景对原始特征的关注程度存在较大差异，该层能够根据不同场景的信息生成原始特征的权重，并利用这些权重对输入特征进行相应的变换，实现场景特定的个性化输入表征，提高模型的场景信息捕捉能力。


• 场景知识迁移：使用GRU门控单元构建场景知识迁移层（Scene Transfer Layer）。GRU门控单元通过场景上下文信息对来自全局场景专家和当前场景专家的信息流动进行控制，筛选出符合当前场景的有用信息；并且，该结构能以层级方式进行堆叠，不断对场景输出进行修正。

场景特征适配在输入层根据场景信息对不同特征进行权重适配，筛选出当前场景下模型最关注的特征；场景知识迁移在隐层专家网络中进行知识迁移，控制共享专家中共性信息向场景独有信息的流动，使得场景共性信息得以传递。

这两种知识迁移方式互为补充、相辅相成，共同提升多场景模型的预估能力。我们对比了不同模块的实验效果，具体结果如下表1所示。可以看出，引入场景知识迁移和特征权重优化在头部、尾部渠道都能带来一定提升，其中尾部小流量场景上（见下表1子场景2、3）有更为明显的提升，可见场景知识迁移缓解了场景之间的负迁移现象。

相关研究和实践表明^[6][7][8]，稀疏专家网络对于提高计算效率和增强模型效果非常有用。因此，我们在AKTN模型的基础上，在专家层进一步优化多场景模型。具体的，我们将场景知识迁移层替换为自动化稀疏专家选择方法，通过门控网络从大规模专家中选取与当前场景最相关的$K$个构成自适应场景表征，其选择过程如下图4所示：

在实践中，我们通过使用可微门控网络对专家进行有效组合，以避免不相关任务之间的负迁移现象。同时大规模专家网络的引入扩大了多场景模型的选择空间，更好地支持了门控网络的选择。考虑到多场景下的海量流量和复杂场景特征，在业界调研的基础上对稀疏专家门控网络进行了探索。

具体而言，我们对以下稀疏门控方法进行了实践：

• 方法一：通过$KL$散度衡量子场景与各专家之间的相似度，以此选择与当前场景最匹配的$k$个专家。在实现方式上，使用场景*专家的二维矩阵计算相似性，并通过$KL$散度选择出最适合的$k$个专家。


• 方法二：每个子场景配备一个专家选择门控网络，$m$个场景则有$m$个门控网络。对于每个场景的门控网络，配备$k$个单专家选择器^[9]，每个单专家选择器负责从$n$个专家中选择一个作为当前场景的专家（$n$为Experts个数）。在实践中，为提高训练效率，我们对单专家选择器中权重较小的值进行截断，保证每个单专家选择器仅选择一个专家。

在离线实验中，我们以物料推荐渠道 * 展示形态作为场景定义，对上述稀疏门控方法进行了尝试，离线效果如下表2所示：

可以看出，基于软共享机制的专家聚合方法能够更好地通过所激活的相同专家网络对各场景之间的知识进行共享。相较于常见的以截断方式为主的门控网络，使用二进制编码的方式使得其在不损失其他专家网络信息的同时，能够更好地收敛到目标专家数量，同时其可微性使得其在以梯度为基础的优化算法中训练更加稳定。

同时，为了验证稀疏门控网络能否有效区分不同场景并捕捉到场景间差异性，我们使用$n$=16个专家中选择$K$=7个的例子，对验证集中不同场景下各专家的利用率、选择专家的平均权重进行了可视化分析（如图5-图7所示），实验结果表明该方法能够有效地选择出不同的专家对场景进行表达。

例如，图6中KP_1更多地选择第5个专家，而KP_2更倾向于选择第15个专家。并且，不同场景对各专家的使用率以及选择专家的平均权重也有着明显的差异性，表明该方法能够捕捉到细分场景下流量的差异性并进行差异化的表达。

实验证明，在通过大规模专家网络对每个场景进行建模的同时，基于软共享机制的专家聚合方法能够更好地通过所激活的相同专家网络对各场景之间的知识进行共享。 同时，为了进一步探索Experts个数对模型性能的影响，我们在方法二的基础上通过调整专家个数和topK比例设计了多组对比实验，实验结果如下表3所示：

从实验数据可以看出，大规模的Experts结构会带来正向的离线收益；并且随着选取专家个数比例的增加（表3横轴），模型整体的表现效果也有上升的趋势。

2.2 自适应场景聚合

理想情况下，一条请求（流量）可以看作一个独立的场景。但如引言所述，随着DSP业务持续发展，不同的物料展示渠道、形式、位置等持续增加，每个场景的数据十分稀疏，我们无法对每个细分场景进行有效训练。因此，我们需要对各个推荐场景进行聚类、合并。我们使用场景聚合的方法对此问题进行求解，通过衡量所有场景间的相似度，并最大化该相似度来指导场景的聚合，解决了数据稀疏导致难以收敛的问题。具体的，我们将该问题表示为：

其中$G$表示某种分组方式，$f_{s_i}$为场景$s_i$在分组$G_k$内与其他场景的总体相似度。在将$N$个场景聚合成$K$个场景组的过程中，我们需要找到使得场景间整体相似度最大的分组方式$G^{\ast}$。

因此，我们在2.1节场景知识迁移模型的基础上，增加了场景聚合部分，提出了基于Two-Stage策略进行训练的场景聚合模型：

• Stage 1：基于相似度衡量方法对各场景的相似度进行归纳，并以最大化分组场景的相似度为目标找到各场景的最优聚合方式（如Scene1与Scene 4可聚合为场景组合Scene Gr0up SGA）；


• Stage 2：基于Stage 1得到的场景聚合方式，以交叉熵损失为目标函数最小化各场景下的交叉熵损失。

其中，Stage 2与2.1节中所述一致，本节主要针对Stage 1进行阐述。我们认为，一个有效的场景聚合方法应该能自适应地应对流量变化的趋势，能够发现场景之间的内在联系并依据当前流量特点自动适配聚合方法。我们首先想到的是从规则出发，将人工先验知识作为场景聚合的依据，按照推荐渠道、展示形式以及两者叉乘的方式进行了相应迭代。然而这类场景聚合方式需要可靠的人工经验来支撑，且在应对海量流量时不能迅速捕捉到其中的变化。

因此，我们对场景之间关系的建模方法进行了相关的探索。首先，我们通过离线训练时场景之间的表征迁移和组合训练来评估场景之间的影响，但这种方式存在组合空间巨大、训练耗时较长的问题，效率较低。

在多任务的相关研究中^{[10][11][12][13]}，使用梯度信息对任务之间的关系进行建模是一种有效的方法。类似的在多场景模型中，能够根据各场景损失函数的梯度信息对场景间的相似度进行建模，因此我们采用多专家网络并基于梯度信息自动化地对场景之间的相似度进行求解，模型示意如下图8所示：

基于上述思路，我们对场景之间的关系建模方法进行了以下尝试：

1. Gradient Regulation

基于梯度信息能够对场景信息进行潜在表示这一认知，我们在损失函数中加入各场景损失函数关于专家层梯度距离的正则项，整体的损失函数如下所示，该正则项的系数$\lambda_{s_i,s_j}$表示场景之间的相似度，$dist$为常见的评估梯度之间距离的方法，比如$l_1$，$l_2$距离。

2. Lookahead Strategy

3. Meta Weights

Lookahead Strategy该方法对场景间的关系进行了显式建模，但是这种根据损失函数的变化计算场景相关系数的策略存在着训练不稳定、波动较大的现象，无法像Gradient Regulation这一方法对场景相似度进行求解。

因此，我们引入了场景间的相关性系数矩阵（meta weights），结合前两种方法对该问题进行如下建模，通过场景$s_i$的数据对其与其他场景的相关性系数$\lambda_{s_i \to s_j}$进行更新，同时基于该参数对全局的参数模型$W$进行优化。针对这种典型的两层优化问题，我们基于MAML^[14]方法进行求解，并将meta weights作为场景间的相似度。

我们以推荐渠道和展示形式（是否开屏）的多场景模型作为Base，对上述3种方法做了探索。为了提高训练效率，我们在设计 Stage 1 模型时做了以下优化：

我们对每个方法的GAUC进行了比较，实验效果如下表4所示。相较于人工规则，基于梯度的场景聚合方法都能带来效果的明显提升，表明损失函数梯度能在一定程度上表示场景之间的相似性，并指导多场景进行聚合。

为了更全面的展现场景聚合对于模型预估效果的影响，我们选取Meta Weights进行分组数量的调优实验，具体的实验结果如下表5所示。可以发现：随着分组数的增大，GAUC提升也越大，此时各场景间的负迁移效应减弱；但分组超过一定数量时，场景间总体的相似度减小，GAUC呈下降趋势。

此外，我们对Meta Weigts方法中部分场景间的关系进行了可视化分析，分析结果如下图9所示。以场景作为坐标轴，图中的每个方格表示各场景间的相似度，颜色的深浅表示渠道间的相似程度大小。

从图中可以发现，以渠道和展示形式为粒度的细分场景下，该方法能够学习到不同场景间的相关性，例如A渠道下的信息流(s16)与其他场景的相关性较低，会将其作为独立的场景进行预估，而B渠道下的开屏展示（s9）与C渠道开屏展示（s8）相关性较高，会将其聚合为一个场景进行预估，同时该相似度矩阵不是对称的，这也说明各场景间相互的影响存在着差异。

3 总结与展望

通过多场景学习的探索和实践，我们深入挖掘了推荐模型在不同场景下的建模能力，并分别从场景知识迁移、场景聚合方向进行了尝试和优化，这些尝试提供了更好的理解和解释推荐模型对不同类型流量和场景的应对能力。然而，这只是多场景学习研究的开始，后续我们会探索并迭代以下方向：

• 更好的场景划分方式：当前多场景的划分主要还是依据渠道（渠道*展示形态）作为流量的划分方式，未来会在媒体、展示位、媒体*时间等维度上进行更详细地探索；


• 端到端的流量聚合方式：在进行流量聚合时，使用了Two-Stage的策略进行聚合。然而，这种方式不能充分地利用流量数据中相关的信息。因此，需要探索端到端的流量场景聚合方案将更直接和有效地提高推荐模型的能力。

结合多场景学习，在未来的研究中将不断探索新的方法和技术，以提高推荐模型对不同场景和流量类型的建模能力，创造更好的用户体验以及商业价值。

4 作者简介

王驰、森杰、树立、文帅、尹华、肖雄等，均来自美团到家事业群/到家研发平台。

5 参考文献

• [1] STAR：Sheng, Xiang-Rong, et al. "One model to serve all: Star topology adaptive recommender for multi-domain ctr prediction." Proceedings of the 30th ACM International Conference on Information & Knowledge Management. 2021.


• [2] SAML：Chen, Yuting, et al. "Scenario-aware and Mutual-based approach for Multi-scenario Recommendation in E-Commerce." 2020 International Conference on Data Mining Workshops (ICDMW). IEEE, 2020.


• [3] ADIN：Jiang, Yuchen, et al. "Adaptive Domain Interest Network for Multi-domain Recommendation." Proceedings of the 31st ACM International Conference on Information & Knowledge Management. 2022.


• [4]SASS：Zhang, Yuanliang, et al. "Scenario-Adaptive and Self-Supervised Model for Multi-Scenario Personalized Recommendation." Proceedings of the 31st ACM International Conference on Information & Knowledge Management. 2022.


• [5] Squeeze-and-Excitation：Hu, Jie, Li Shen, and Gang Sun. "Squeeze-and-excitation networks." Proceedings of the IEEE conference on computer vision and pattern recognition. 2018.


• [6] 美团外卖推荐情境化智能流量分发的实践与探索


• [7] PaLM：ai.googleblog.com/2022/04/pat…


• [8] GLaM：proceedings.mlr.press/v162/du22c.…


• [9] 单专家选择器：arxiv.org/abs/2106.03…


• [10] HOA：proceedings.mlr.press/v119/standl…


• [11] Gradient Affinity：proceedings.neurips.cc/paper/2021/…


• [12] SRDML：dl.acm.org/doi/abs/10.…


• [13] Auto-Lambda：arxiv.org/abs/2202.03…


• [14] MAML：arxiv.org/abs/1703.03…

myapp

  |--package.json

  |--index.js  

// index.js

console.log(t("中华人民共和国万岁"))

console.log(t("中华人民共和国成立于{}",1949))

> npm install -g @voerkai18n/cli

> yarn global add @voerkai18n/cli

> pnpm add -g @voerkai18/cli

> voerkai18n init 

{

    "languages": [

        {

            "name": "zh",

            "title": "zh"

        },

        {

            "name": "en",

            "title": "en"

        }

    ],

    "defaultLanguage": "zh",

    "activeLanguage": "zh",

    "namespaces": {}

}

import { t } from "./languages"

// 不含插值变量

t("中华人民共和国")

// 位置插值变量

t("中华人民共和国{}","万岁")

t("中华人民共和国成立于{}年，首都{}",1949,"北京")

myapp>voerkai18n extract

myapp

  |-- languages

    |-- settings.json                // 语言配置文件

    |-- translates                   // 此文件夹是所有需要翻译的内容

      |-- default.json               // 默认名称空间内容

  |-- package.json

  |-- index.js

myapp>voerkai18n extract -D -lngs zh en de jp -d zh -a zh

{

    "中华人民共和国万岁":{

        "en":"<在此编写对应的英文翻译内容>",

        "de":"<在此编写对应的德文翻译内容>",

        "jp":"<在此编写对应的日文翻译内容>",

        "$files":["index.js"]    // 记录了该信息是从哪几个文件中提取的

    },

	"中华人民共和国成立于{}":{

        "en":"<在此编写对应的英文翻译内容>",

        "de":"<在此编写对应的德文翻译内容>",

        "jp":"<在此编写对应的日文翻译内容>",

        "$files":["index.js"]

    }

}

>voerkai18n translate --appkey <在百度翻译上申请的密钥> --appid <在百度翻译上申请的appid>

myapp> voerkai18n compile

  |-- languages

    |-- settings.json                // 语言配置文件

    |-- idMap.js                     // 文本信息id映射表

    |-- index.js                     // 包含该应用作用域下的翻译函数等

    |-- storage.js

    |-- zh.js                        // 语言包

    |-- en.js

    |-- jp.js

    |-- de.js

    |-- formatters                   // 自定义扩展格式化器

        |-- zh.js                     

        |-- en.js

        |-- jp.js

        |-- de.js

    |-- translates                   // 此文件夹包含了所有需要翻译的内容

      |-- default.json

  |-- package.json

  |-- index.js

import { t } from "./languages"   

import { i18nScope } from "./languages"



// 切换到英文

await i18nScope.change("en")

// 或者VoerkaI18n是一个全局单例，可以直接访问

await VoerkaI18n.change("en")

import { i18nScope } from "./languages"



// 切换到英文

i18nScope.on("change",(newLanguage)=>{

    // 在此重新渲染界面

    ...



})

// 

VoerkaI18n.on("change",(newLanguage)=>{

     // 在此重新渲染界面

     ...

})

import { i18nScope } from "./languages"



i18nScope.registerDefaultLoader(async (language,scope)=>{

    return await (await fetch(`/languages/${scope.id}/${language}.json`)).json()

})

更完整的说明详见动态加载语言包和语言包补丁功能介绍。

大家好，我是拭心。

前段时间组里有岗位招人，花了些时间面试，趁着周末把过程中的感悟和槽点总结成文和大家讲讲。

简历书写和自我介绍

2. 去年工作经历都是小公司的还有几个进了面试，今年基本没有，在 HR 第一关就被刷掉了


3. 这种情况的，一定要走内推，让内推的人跟 HR 打个招呼：这人技术不错，让用人部门看看符不符合要求


4. 用人部门筛简历也看学历经历，但更关注这几点：过去做了什么项目、项目经验和岗位对不对口、项目的复杂度怎么样、用到的技术栈如何、他在里面是什么角色


5. 如果项目经历不太出彩，简历上可以补充些学习博客、GitHub，有这两点的简历我都会点开仔细查看，印象分会好很多


6. 现在基本都视频面试，面试的时候一定要找个安静的环境、体态认真的回答。最好别用手机，否则会让人觉得不尊重！


7. 我面过两个神人，一个在马路上边走边视频；另一个聊着聊着进了卫生间，坐在马桶上和我讲话（别问我怎么知道在卫生间的，他努力的声音太大了。。。）


8. 自我介绍要自然一点，别像背课文一样好吗亲。面试官不是考你背诵，是想多了解你一点，就当普通聊天一样自然点


9. 介绍的时候不要过于细节，讲重点、结果、数据，细节等问了再说


10. 准备介绍语的时候问问自己，别人可以得到什么有用的信息、亮点能不能让对方快速 get 到


11. 实在不知道怎么介绍，翻上去看第 4 点和第 5 点


12. 出于各种原因，很多面试官在面试前没看过你的简历，在你做自我介绍时，他们也在一心二用 快速地浏览你的简历。所以你的自我介绍最好有吸引人的点，否则很容易被忽略


13. 你可以这样审视自己的简历和自我介绍：
    
    

    a. 整体：是否能清晰的介绍你的学历、工作经历和技能擅长点

    
    

    b. 工作经历：是否有可以证明你有能力、有结果的案例，能否从中看出你的能力和思考

    
    

    c. 技能擅长点：是否有岗位需要的大部分技能，是否有匹配工作年限的复杂能力，是否有区别于其他人的突出点

什么是 Tauri

Tauri 是一个跨平台的 GUI 框架，与 Electron 的理念相似。Tauri 的前端部分同样基于 Web 技术，但它的后端则采用了 Rust 语言。Tauri 可以创建体积更小、运行更快且更加安全的跨平台桌面应用。

与 Electron 不同，Tauri 并没有内置 Chromium，因此打包后的应用体积要比 Electron 小很多，启动速度更快，内存和 CPU 占用率也更低。

然而，由于没有内置 Chromium，Tauri 使用系统原生的 WebView 来渲染网页，这可能导致不同系统之间的页面表现存在差异。同时，Tauri 的后端需要使用 Rust 进行开发，这对前端开发人员来说可能会有一定的上手成本。

好在 Tauri 已经为我们封装了大部分 API，即使不懂 Rust，也可以开发出一款简单的应用。

预先准备

我们以 macOS 为例：

1. 首先安装 Xcode 命令行工具

在终端中执行以下命令：

xcode-select --install

如果已经安装过 Xcode 命令行工具，则可以直接进行下一步。

2. 安装 Rust

在 macOS 上安装 Rust，请打开终端并输入以下命令：

curl --proto '=https' --tlsv1.2 https://sh.rustup.rs -sSf | sh

安装成功后，终端将显示以下内容：

Rust is installed now. Great!

请确保重新启动终端以使更改生效。

快速开始

创建项目

Tauri 官方提供了多种项目模板，可以快速搭建项目：

# pnpm

pnpm create tauri-app



# npm

npm create tauri-app



# yarn

yarn create tauri-app

按照提示选择自己喜欢的模板。

这里我们选择 react 开发前端页面。

一路回车后，打开项目文件夹。执行安装依赖命令：pnpm i。依赖安装完成后，执行 pnpm tauri dev 命令启动项目。这时便会启动一个应用，如下图所示：

开发

Tauri 的开发非常容易上手，我们先来看下项目文件结构：

是不是和 Vite 的目录结构一样？

没错，这就是一个常规的 Vite 目录结构，唯一的区别是增加了一个 src-tauri 文件夹，这里面是 Rust 部分的代码，也就是后端代码。

打包

首先，我们需要修改默认的包标识符，位置在 src-tauri > tauri.conf.json > tauri > bundle > identifier。

这里我们随便填写一个标识符 com.example.app，保存，然后执行命令：pnpm tauri build 就可以正常打包了。

tauri.conf.json 文件是我们的应用配置文件，包含了应用的基本信息。

打包完成后，就可以在 tauri-app/src-tauri/target/release/bundle 目录下找到我们的应用。

现在我们只构建了 macOS 下的应用。

打开之后就可以看到我们的应用了。

参考文档

• Tauri 中文网

背景：

充血模型是DDD分层架构中实体设计的一种方案，可以使关注点聚焦于业务实现，可有效提升开发效率、提升可维护性；

1、DDD项目落地整体调用关系

调用关系图中的Entity为实体，从进入领域服务（Domin）时开始使用，直到最后返回。

2、实体设计

充血模型是实体设计的一种方法，简单来说，就是一种带有具体行为方法和聚合关联关系的特殊实体；

关于实体设计，需要明白的关键词为：领域服务->聚合->聚合根->实体->贫血模型->充血模型

聚合与聚合根:

聚合是一种关联关系，而聚合根就是这个关系成立的基础，没有聚合根，这个聚合关系就无法成立；

举个例子，存在3个实体：用户、用户组、用户组关联关系，这3个实体形成的关联关系就是聚合，而用户实体就是这个聚合中的聚合根；

实体：

定义在领域层，是领域层的重要元素，从领域划分到工程实践落地，都应该围绕实体进行，DDD中的实体和数据库表不只是1对1关系，可能是1对多或者仅为内存中的对象；

贫血模型：

实体不带有任何行为方法，也不带有聚合关联关系，作用基本相当于值对象（ValueObject），仅作为值传递的对象，和传统三层项目架构中的实体具有相同作用，不建议使用。补充说明：一般我们使用的DTO就可以被当做是值对象

充血模型：

实体中带有具有行为方法和聚合关联关系，行为方法是说create、save、delete等封装了一类可以指代行为的方法，比如在用户实体对象中具有用户组实体的引用，这样当我们需要操作用户组时，只通过用户实体进行操作就可以。

工程实践中，建议采用充血模型，好处是隐藏胶水代码，提升代码可读性，使关注点聚焦于业务实现。

充血模型在实践中的问题：

行为代码量过多，导致实体内部臃肿膨胀，难以阅读，难以维护，对于这种问题，我们需要根据实体行为的代码量多少来采取不同的解决方案。

解决方案：

场景1：行为不会导致实体臃肿的情况下，在实体中完成行为定义

public CooperateServicePackageConfig save() {    

    // 直接调用基础设施层进行保存

    cooperateServicePackageConfigRepository.save(this);    

    return this;

}

场景2：行为导致实体臃肿的情况下，采用外部定义行为的方式，核心思想是借助其他类实现行为代码定义，将臃肿代码外移，保留干净的实体行为：

1）创建工具类，将某个实体中的行为定义其中，实体负责调用该工具类

public CooperateServicePackageConfig save() {    

    // 将处理过程放在工具类中

    ServicePackageSaveUtils.save(this);   

    return this;

 }

2）创建新实体，将该实体的使用场景明确至某个细分行为，比如一个聚合根（ExampleEntity）的保存可能涉及到5个实体的保存，那么我们定义一个ExampleSaveEntity实体，专门用来处理该聚合下的保存行为

实践经验：

1、关于spring bean注入：充血模型在实体中使用静态注入方法实现。例：

private LabelInfoRepository labelInfoRepository = ApplicationContextUtils.getBean(LabelInfoRepository.class);

2、充血模型的实体序列化，排除非必要属性，在一些redis对象缓存时可能会用到。例：

// 使用注解排除序列化属性

@Getter(AccessLevel.NONE)

private LabelInfoRepository labelInfoRepository = ApplicationContextUtils.getBean(LabelInfoRepository.class);

// 使用注解排除序列化属性

@JSONField(serialize = false)

private ServicePackageConfig servicePackageConfig;

// 使用注解排除序列化 get 方法

@Transient

@JSONField(serialize = false)

public static CooperateServicePackageRepositoryQuery getAllCodeQuery(Long contractId) {    

    CooperateServicePackageRepositoryQuery repositoryQuery = new CooperateServicePackageRepositoryQuery();    

    repositoryQuery.setContractIds(com.google.common.collect.Lists.newArrayList(contractId));    

    repositoryQuery.setCode(RightsPlatformConstants.CODE_ALL);   

     return repositoryQuery;

}

3、利用Set方法建立聚合绑定关系。例：

public void setServiceSkuInfos(List<ServiceSkuInfo> serviceSkuInfos) {    

    if (CollectionUtils.isEmpty(serviceSkuInfos)) 

    {        

        return;    

    }    

    this.serviceSkuInfos = serviceSkuInfos;    

    List<String> allSkuNoSet = serviceSkuInfos

                                .stream()

                                .map(one -> one.getSkuNo())

                                .collect(Collectors.toList());   

     String skuJoinStr = Joiner.on(GlobalConstant.SPLIT_CHAR).join(allSkuNoSet);    

     this.setSkuNoSet(skuJoinStr);}

作者：京东健康 张君毅

来源：京东云开发者社区

说到布局很多人的感觉应该都是恐惧，为此很多人都背过一些很经典的布局方案，例如：圣杯布局、双飞翼布局等非常耳熟的名词；

为了实现这些布局我们有很多种实现方案，例如：table布局、float布局、定位布局等，当然现在比较流行的肯定是flex布局；

flex布局属于弹性布局，所谓弹性也可以理解为响应式布局，而同为响应式布局的还有Grid布局；

Grid布局是一种二维布局，可以理解为flex布局的升级版，它的出现让我们在布局方面有了更多的选择，废话不多说，下面开始全程高能；

本篇不会过多介绍grid的基础内容，更多的是一些布局的实现方案和一些小技巧；

常见布局

所谓的常见布局只是我们在日常开发中经常会遇到的布局，例如：圣杯布局、双飞翼布局这种名词我个人觉得不用太过于去在意；

因为这类布局最后的解释都会变成几行几列，内容在哪一行哪一列，而这些就非常直观的对标了grid的特性；

接下来我们来一起看看一些非常常见的布局，并且用grid来实现；

1. 顶部 + 内容

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <title>Title</title>

    <style>

        html, body {

            margin: 0;

            padding: 0;

        }



        body {

            display: grid;

            grid-template-rows: 60px 1fr;

            height: 100vh;

        }



        .header {

            background-color: #039BE5;

        }



        .content {

            background-color: #4FC3F7;

        }



        .header,

        .content {

            display: flex;

            align-items: center;

            justify-content: center;

            font-size: 24px;

        }

    </style>

</head>

<body>

<div class="header">Header</div>

<div class="content">Content</div>

</body>

</html>

2. 顶部 + 内容 + 底部

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <title>Title</title>

    <style>

        html, body {

            margin: 0;

            padding: 0;

        }



        body {

            display: grid;

            grid-template-rows: 60px 1fr 60px;

            height: 100vh;

        }



        .header {

            background-color: #039BE5;

        }



        .content {

            background-color: #4FC3F7;

        }



        .footer {

            background-color: #039BE5;

        }



        .header,

        .content,

        .footer {

            display: flex;

            align-items: center;

            justify-content: center;

            font-size: 24px;

        }

    </style>

</head>

<body>

<div class="header">Header</div>

<div class="content">Content</div>

<div class="footer">Footer</div>

</body>

</html>

这里示例和上面的示例唯一的区别就是多了一个footer，但是我们可以看到代码并没有多少变化，这就是grid的强大之处；

可以看码上掘金的效果，这里的内容区域是单独滚动的，从而实现了header和footer固定，内容区域滚动的效果；

实现这个效果也非常简单，只需要在content上加上overflow: auto即可；

3. 左侧 + 内容

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <title>Title</title>

    <style>

        html, body {

            margin: 0;

            padding: 0;

        }



        body {

            display: grid;

            grid-template-columns: 240px 1fr;

            height: 100vh;

        }



        .left {

            background-color: #039BE5;

        }



        .content {

            background-color: #4FC3F7;

        }

        

        .left,

        .content {

            display: flex;

            align-items: center;

            justify-content: center;

            font-size: 24px;

        }





    </style>

</head>

<body>

<div class="left">Left</div>

<div class="content">Content</div>

</body>

</html>

这个示例效果其实和第一个是类似的，只不过是把grid-template-rows换成了grid-template-columns，这里就不提供码上掘金的示例了；

4. 顶部 + 左侧 + 内容

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <title>Title</title>

    <style>

        html, body {

            margin: 0;

            padding: 0;

        }



        body {

            display: grid;

            grid-template-rows: 60px 1fr;

            grid-template-columns: 240px 1fr;

            height: 100vh;

        }



        .header {

            grid-column: 1 / 3;

            background-color: #039BE5;

        }



        .left {

            background-color: #4FC3F7;

        }



        .content {

            background-color:  #99CCFF;

        }



        .header,

        .left,

        .content {

            display: flex;

            align-items: center;

            justify-content: center;

            font-size: 24px;

        }

        

    </style>

</head>

<body>

<div class="header">Header</div>

<div class="left">Left</div>

<div class="content">Content</div>

</body>

</html>

这个示例不同点在于header占据了两列，这里我们可以使用grid-column来实现，grid-column的值是start / end，例如：1 / 3表示从第一列到第三列；

如果确定这一列是占满整行的，那么我们可以使用1 / -1来表示，这样如果后续变成顶部 + 左侧 + 内容 + 右侧的布局，那么header就不需要修改了；

5. 顶部 + 左侧 + 内容 + 底部

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <title>Title</title>

    <style>

        html, body {

            margin: 0;

            padding: 0;

        }



        body {

            display: grid;

            grid-template-areas:

            "header header"

            "left content"

            "left footer";

            grid-template-rows: 60px 1fr 60px;

            grid-template-columns: 240px 1fr;

            height: 100vh;

        }



        .header {

            grid-area: header;

            background-color: #039BE5;

        }



        .left {

            grid-area: left;

            background-color: #4FC3F7;

        }



        .content {

            grid-area: content;

            background-color: #99CCFF;

        }



        .footer {

            grid-area: footer;

            background-color: #6699CC;

        }



        .header,

        .left,

        .content,

        .footer {

            display: flex;

            align-items: center;

            justify-content: center;

            font-size: 24px;

        }

    </style>

</head>

<body>

<div class="header">Header</div>

<div class="left">Left</div>

<div class="content">Content</div>

<div class="footer">Footer</div>

</body>

</html>

这个示例的小技巧是使用了grid-template-areas，使用这个属性可以让我们通过代码来直观的看到布局的样式；

这里的值是一个字符串，每一行代表一行，每个字符代表一列，例如："header header"表示第一行的两列都是header，这里的header是我们自己定义的，可以是任意值；

定义好了之后就可以在对应的元素上使用grid-area来指定对应的区域，这里的值就是我们在grid-template-areas中定义的值；

在码上掘金中的效果可以看到，左侧的菜单和内容区域都是单独滚动的，这里的实现方式和第二个示例是一样的，只需要需要滚动的元素上加上overflow: auto即可；

响应式布局

响应式布局指的是页面的布局会随着屏幕的大小而变化，这里的变化可以是内容区域大小可以自动调整，也可以是页面布局随着屏幕大小进行自动调整；

这里我就用掘金的页面来举例，这里只提供一个思路，所以不会像上面那样提供那么多示例；

1. 基础布局实现

移动端布局

以移动端的效果开始，掘金的移动端的布局就是上面的效果，这里我简单的将页面分为了三个部分，分别是header、navigation、content；

注：这里不是要100%还原掘金的页面，只是为了演示grid布局，具体页面结构和最后实现的效果会有非常大的差异，这里只会实现一些基础的布局；

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <title>Title</title>

    <style>

        html, body {

            margin: 0;

            padding: 0;

        }



        body {

            display: grid;

            grid-template-areas:

            "header"

            "navigation"

            "content";

            grid-template-rows: 60px 48px 1fr;

            height: 100vh;

        }



        .header {

            grid-area: header;

            background-color: #039BE5;

        }



        .navigation {

            grid-area: navigation;

            background-color: #4FC3F7;

        }



        .content {

            grid-area: content;

            background-color: #99CCFF;

        }





        .header,

        .navigation,

        .content {

            display: flex;

            align-items: center;

            justify-content: center;

            font-size: 24px;

        }



    </style>

</head>

<body>

<div class="header">Header</div>

<div class="navigation">Navigation</div>

<div class="content">Content</div>

</body>

</html>

iPad布局

这里是需要借助媒体查询来实现的，在媒体查询中只需要调整一下grid-template-rows和grid-template-columns的值即可；

由于这里的效果是上面一个的延伸，为了阅读体验会移除上面相关的css代码，只保留需要修改的代码；

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <title>Title</title>

    <style>



        .right {

            display: none;

            background-color: #6699CC;

        }



        @media (min-width: 1000px) {

            body {

                grid-template-areas:

                  "header header"

                  "navigation navigation"

                  "content right";

                grid-template-columns: 1fr 260px;

            }



            .right {

                grid-area: right;



                display: flex;

                align-items: center;

                justify-content: center;

                font-size: 24px;

            }

        }

    </style>

</head>

<body>

<div class="header">Header</div>

<div class="navigation">Navigation</div>

<div class="content">Content</div>

<div class="right">Right</div>

</body>

</html>

PC端布局

和上面处理方式相同，由于Navigation移动到了左侧，所以还要额外的修改一下grid-template-areas的值；

这里就可以体现grid的强大之处了，我们可以简单的修改grid-template-areas就可以实现一个完全不同的布局，而且代码量非常少；

为了居中显示内容，我们需要在左右两侧加上一些空白区域，可以简单的使用.来实现，这里的.表示一个空白区域；

由于内容的宽度基本上是固定的，所以留白区域简单的使用1fr进行占位即可，这样就可以平均的分配剩余的空间；

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <title>Title</title>

    <style>

        @media (min-width: 1220px) {

            body {

                grid-template-areas:

                  "header header header header header"

                  ". navigation content right .";

                grid-template-columns: 1fr 180px minmax(0, 720px) 260px 1fr;

                grid-template-rows: 60px 1fr;

            }

        }

    </style>

</head>

<body>

<div class="header">Header</div>

<div class="navigation">Navigation</div>

<div class="content">Content</div>

<div class="right">Right</div>

</body>

</html>

完善一些细节

最终的布局大概就是上图这样，这里主要处理的各个版块的间距和响应式内容区域的大小，这里的处理方式主要是使用column-gap和一个空的区域进行占位来实现的；

这里的column-gap表示列与列之间的间距，值可以是px、em、rem等基本的长度属性值，也可以使用计算函数，但是不能使用弹性值fr；

空区域进行占位留间距其实我并不推荐，这里只是演示grid布局可以实现的一些功能，具体的实现方式还是要根据实际情况来定，这里我更推荐使用margin来实现；

完整代码如下：

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <title>Title</title>

    <style>

        html, body {

            margin: 0;

            padding: 0;

        }



        body {

            display: grid;

            grid-template-areas:

            "header header header"

            "navigation navigation navigation"

            ". . ."

            ". content .";

            grid-template-columns: 1fr minmax(0, 720px) 1fr;

            grid-template-rows: 60px 48px 10px 1fr;

            column-gap: 10px;

            height: 100vh;

        }



        .header {

            grid-area: header;

            background-color: #039BE5;

        }



        .navigation {

            grid-area: navigation;

            background-color: #4FC3F7;

        }



        .content {

            grid-area: content;

            background-color: #99CCFF;

        }



        .right {

            display: none;

            background-color: #6699CC;

        }



        @media (min-width: 1000px) {

            body {

                grid-template-areas:

                  "header header header header"

                  "navigation navigation navigation navigation"

                  ". . . ."

                  ". content right .";

                grid-template-columns: 1fr minmax(0, 720px) 260px 1fr;

            }



            .right {

                grid-area: right;



                display: flex;

                align-items: center;

                justify-content: center;

                font-size: 24px;

            }

        }



        @media (min-width: 1220px) {

            body {

                grid-template-areas:

                  "header header header header header"

                  ". . . . ."

                  ". navigation content right .";

                grid-template-columns: 1fr 180px minmax(0, 720px) 260px 1fr;

                grid-template-rows: 60px 10px 1fr;

            }

        }



        .header,

        .navigation,

        .content {

            display: flex;

            align-items: center;

            justify-content: center;

            font-size: 24px;

        }



    </style>

</head>

<body>

<div class="header">Header</div>

<div class="navigation">Navigation</div>

<div class="content">Content</div>

<div class="right">Right</div>

</body>

</html>

简单复刻版

以码上掘金上的效果来说已经完成了大部分的布局和一些效果，目前来说就是还差一些交互，还有一些细节上的处理，感兴趣的同学可以自行完善；

异型布局

异性布局指的是页面中的元素不是按照常规的流式布局进行排版，又或者说不规则的布局，这里我简单的列出几个布局，来看看grid是如何实现的；

1. 照片墙

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <title>Title</title>

    <style>

        html, body {

            margin: 0;

            padding: 0;

            background: #f2f3f5;

            overflow: auto;

        }



        body {

            display: grid;

            grid-template-columns: repeat(12, 100px);

            grid-auto-rows: 100px;

            place-content: center;

            gap: 6px;

            height: 100vh;

        }



        .photo-item {

            width: 200px;

            height: 200px;

            clip-path: polygon(50% 0, 100% 50%, 50% 100%, 0 50%);

        }



    </style>

</head>

<body>



</body>

<script>

    function randomColor() {

        return '#' + Math.random().toString(16).substr(-6);

    }



    let row = 1;

    let col = 1;

    for (let i = 0; i < 28; i++) {

        const div = document.createElement('div');

        div.className = 'photo-item';

        div.style.backgroundColor = randomColor();

        div.style.gridRow = `${row} / ${row + 2}`;

        div.style.gridColumn = `${col} / ${col + 2}`;



        document.body.appendChild(div);

        col += 2;

        if (col > 11) {

            row += 1;

            col = row % 2 === 0 ? 2 : 1;

        }

    }

</script>

</html>

这是一个非常简单的照片墙效果，如果不使用grid的话，我们大概率是会使用定位去实现这个效果，但是换成grid的话就非常简单了；

而且代码量是非常少的，这里就不提供码上掘金的 demo 了，感兴趣的同学可以将代码复制下来自行查看效果；

2. 漫画效果

在漫画中有很多类似这种不规则的漫画框，如果使用定位的话，那么代码量会非常大，而且还需要计算一些位置，使用grid的话就非常简单了；

可以看到这里还有一个气泡文字显示的效果，按照页面书写顺序，气泡是不会显示的，这里我们可以使用z-index来实现，这里的z-index值越大，元素就越靠前；

而且气泡文字效果也是通过grid来进行排版的，并没有使用其他的布局来实现，代码量也并不多，感兴趣的同学可以自行查看；

3. 画报效果

在一个画报中，我们经常会看到文字和图片混合排版的效果，由于这里直接使用的是渐变的背景，而且我的文字都是随意进行排列的，没有什么规律，所以看起来会比较混乱；

在画报效果中看似文字排版非常混乱不规则，但是实际上设计师在设计的时候也是会划分区域的，当然用定位也是没问题的，但是使用grid的话就会简单很多；

我这里将页面划分为12 * 12区域的网格，然后依次对不同的元素进行单独排列和样式的设置；

流式布局

流式布局指的是页面的内容会随着屏幕的大小而变化，流式布局也可以理解为响应式布局；

但是不同于响应式布局的是，流式布局的布局不会像响应式布局那样发生变化，只是内容会随着轴进行流动；

通常这种指的是grid-template-columns: repeat(auto-fit, minmax(0, 1fr))这种；

直接看效果：

这里有两个关键字，一个是auto-fit，还有一个是auto-fill，在行为上它们是相同的，不同的是它们在网格创建的不同，

就像上面图中看到的一样，使用auto-fit会将空的网格进行折叠，可以看到他们的结束colum的数字都是6;

像我们上面的实例中不会出现这个问题，因为我们使用了响应式单位fr，只有使用固定单位才会出现这个现象；

感兴趣的同学可以将minmax(200px, 1fr)换成200px尝试；

对比 Flex 布局

在我上面介绍了这么多的布局场景和案例，其实可以很明显的发现一件事，那就是我使用grid进行的布局基本上都是大框架；

当然上面也有一些布局使用flex也是可以实现的，但是我们再换个思路，除了flex可以做到上面的一些布局，float布局、table布局、定位布局其实也都能实现；

不同的是float布局、table布局、定位布局基本上都是一些hack的方案，就拿table布局来说，table本身就是一个html标签，作用就是用来绘制表格，被拿来当做布局的一种方案也是迫不得已；

而web布局发展到现在的我们有了正儿八经可以布局的方案flex，为什么又要出一个grid呢？

grid的出现绝对不是用来替代flex的，在我上面的实现的一些布局案例中，也可以看到我还会使用flex；

我个人理解的是使用grid进行主体的大框架的搭建，flex作为一些小组件的布局控制，两者搭配使用；

flex能实现一些grid不好实现的布局，同样grid也可以实现flex实现困难的布局；

本身它们的定位就不痛，flex作为一维布局的首选，grid定位就是比flex高一个维度，它的定位是二维布局，所以他们之间没有必要进行对比，合理使用就好；

总结

上面介绍的这么多基于grid布局实现的布局方案，足以看出grid布局的强大；

grid布局的体系非常庞大，本文只是梳理出一些常见的布局场景，通过grid布局去实现这些布局，来体会grid带来的便利；

可能需要完全理解我上面的全部示例需要对grid有一定的了解才可以，但是都看到这里了，不妨去深挖一下；

grid布局作为一项强大的布局技术，有望在未来继续发展，除了我上面说到的布局，grid还有很多小技巧来实现非常多的布局场景；

碍于我的见识和文笔的限制，我这次介绍grid肯定是有很多不足的，但是还是希望这篇文章能为你对于布局相关能有新的认识；

大家好，我是冰河~~

一般家庭网络的公网IP都是不固定的，而我又想通过域名来访问自己服务器上的应用，也就是说：需要通过将域名绑定到动态IP上来实现这个需求。于是乎，我开始探索实现的技术方案。

通过在网上查阅一系列的资料后，发现阿里云可以做到实现动态域名解析DDNS。于是乎，一顿操作下来，我实现了域名绑定动态IP。这里，我们以Python为例实现。

小伙伴们注意啦：Java版源码已提交到：github.com/binghe001/m…

好了，说干就干，我们开始吧，走起~~

阿里云DDNS前置条件

• 域名是在阿里云购买的


• 地址必须是公网地址，不然加了解析也没有用

通过阿里云提供的SDK，然后自己编写程序新增或者修改域名的解析，达到动态解析域名的目的；主要应用于pppoe拨号的环境，比如家里设置了服务器，但是外网地址经常变化的场景；再比如公司的pppoe网关，需要建立vpn的场景。

安装阿里云SDK

需要安装两个SDK库，一个是阿里云核心SDK库，一个是阿里云域名SDK库；

阿里云核心SDK库

pip install aliyun-python-sdk-core

阿里云域名SDK库

pip install aliyun-python-sdk-domain

阿里云DNSSDK库

pip install aliyun-python-sdk-alidns

设计思路

• 获取阿里云的accessKeyId和accessSecret


• 获取外网ip


• 判断外网ip是否与之前一致


• 外网ip不一致时，新增或者更新域名解析记录

实现方案

这里，我直接给出完整的Python代码，小伙伴们自行替换AccessKey和AccessSecret。

#!/usr/bin/env python

#coding=utf-8



# 加载核心SDK

from aliyunsdkcore.client import AcsClient

from aliyunsdkcore.acs_exception.exceptions import ClientException

from aliyunsdkcore.acs_exception.exceptions import ServerException



# 加载获取 、 新增、 更新、 删除接口

from aliyunsdkalidns.request.v20150109 import DescribeSubDomainRecordsRequest, AddDomainRecordRequest, UpdateDomainRecordRequest, DeleteDomainRecordRequest



# 加载内置模块

import json,urllib



# AccessKey 和 Secret  建议使用 RAM 子账户的 KEY 和 SECRET 增加安全性

ID = 'xxxxxxx'

SECRET = 'xxxxxx'



# 地区节点 可选地区取决于你的阿里云帐号等级，普通用户只有四个，分别是杭州、上海、深圳、河北，具体参考官网API

regionId = 'cn-hangzhou'



# 配置认证信息

client = AcsClient(ID, SECRET, regionId)



# 设置主域名

DomainName = 'binghe.com'



# 子域名列表  列表参数可根据实际需求增加或减少值

SubDomainList = ['a', 'b', 'c']



# 获取外网IP   三个地址返回的ip地址格式各不相同，3322 的是最纯净的格式， 备选1为 json格式  备选2 为curl方式获取  两个备选地址都需要对获取值作进一步处理才能使用

def getIp():

    # 备选地址：1， http://pv.sohu.com/cityjson?ie=utf-8    2，curl -L tool.lu/ip

    with urllib.request.urlopen('http://www.3322.org/dyndns/getip') as response:

        html = response.read()

        ip = str(html, encoding='utf-8').replace("\n", "")

    return ip



# 查询记录

def getDomainInfo(SubDomain):

    request = DescribeSubDomainRecordsRequest.DescribeSubDomainRecordsRequest()

    request.set_accept_format('json')



    # 设置要查询的记录类型为 A记录   官网支持A / CNAME / MX / AAAA / TXT / NS / SRV / CAA / URL隐性（显性）转发  如果有需要可将该值配置为参数传入

    request.set_Type("A")



    # 指定查记的域名 格式为 'test.binghe.com'

    request.set_SubDomain(SubDomain)



    response = client.do_action_with_exception(request)

    response = str(response, encoding='utf-8')



    # 将获取到的记录转换成json对象并返回

    return json.loads(response)



# 新增记录 (默认都设置为A记录，通过配置set_Type可设置为其他记录)

def addDomainRecord(client,value,rr,domainname):

    request = AddDomainRecordRequest.AddDomainRecordRequest()

    request.set_accept_format('json')



    # request.set_Priority('1')  # MX 记录时的必选参数

    request.set_TTL('600')       # 可选值的范围取决于你的阿里云账户等级，免费版为 600 - 86400 单位为秒 

    request.set_Value(value)     # 新增的 ip 地址

    request.set_Type('A')        # 记录类型

    request.set_RR(rr)           # 子域名名称  

    request.set_DomainName(domainname) #主域名



    # 获取记录信息，返回信息中包含 TotalCount 字段，表示获取到的记录条数 0 表示没有记录， 其他数字为多少表示有多少条相同记录，正常有记录的值应该为1，如果值大于1则应该检查是不是重复添加了相同的记录

    response = client.do_action_with_exception(request)

    response = str(response, encoding='utf-8')

    relsult = json.loads(response)

    return relsult



# 更新记录

def updateDomainRecord(client,value,rr,record_id):

    request = UpdateDomainRecordRequest.UpdateDomainRecordRequest()

    request.set_accept_format('json')



    # request.set_Priority('1')

    request.set_TTL('600')

    request.set_Value(value) # 新的ip地址

    request.set_Type('A')

    request.set_RR(rr)

    request.set_RecordId(record_id)  # 更新记录需要指定 record_id ，该字段为记录的唯一标识，可以在获取方法的返回信息中得到该字段的值



    response = client.do_action_with_exception(request)

    response = str(response, encoding='utf-8')

    return response



# 删除记录

def delDomainRecord(client,subdomain):

    info = getDomainInfo(subdomain)

    if info['TotalCount'] == 0:

        print('没有相关的记录信息，删除失败！')

    elif info["TotalCount"] == 1:

        print('准备删除记录')

        request = DeleteDomainRecordRequest.DeleteDomainRecordRequest()

        request.set_accept_format('json')



        record_id = info["DomainRecords"]["Record"][0]["RecordId"]

        request.set_RecordId(record_id) # 删除记录需要指定 record_id ，该字段为记录的唯一标识，可以在获取方法的返回信息中得到该字段的值

        result = client.do_action_with_exception(request)

        print('删除成功，返回信息：')

        print(result)

    else:

        # 正常不应该有多条相同的记录，如果存在这种情况，应该手动去网站检查核实是否有操作失误

        print("存在多个相同子域名解析记录值，请核查后再操作！")



# 有记录则更新，没有记录则新增

def setDomainRecord(client,value,rr,domainname):

    info = getDomainInfo(rr + '.' + domainname)

    if info['TotalCount'] == 0:

        print('准备添加新记录')

        add_result = addDomainRecord(client,value,rr,domainname)

        print(add_result)

    elif info["TotalCount"] == 1:

        print('准备更新已有记录')

        record_id = info["DomainRecords"]["Record"][0]["RecordId"]

        cur_ip = getIp()

        old_ip = info["DomainRecords"]["Record"][0]["Value"]

        if cur_ip == old_ip:

            print ("新ip与原ip相同，不更新！")

        else:

            update_result = updateDomainRecord(client,value,rr,record_id)

            print('更新成功，返回信息：')

            print(update_result)

    else:

        # 正常不应该有多条相同的记录，如果存在这种情况，应该手动去网站检查核实是否有操作失误

        print("存在多个相同子域名解析记录值，请核查删除后再操作！")





IP = getIp()



# 循环子域名列表进行批量操作

for x in SubDomainList:

    setDomainRecord(client,IP,x,DomainName)



# 删除记录测试

# delDomainRecord(client,'b.jsoner.com')



# 新增或更新记录测试

# setDomainRecord(client,'192.168.3.222','a',DomainName)



# 获取记录测试

# print (getDomainInfo(DomainName, 'y'))



# 批量获取记录测试

# for x in SubDomainList:

#     print (getDomainInfo(DomainName, x))



# 获取外网ip地址测试

# print ('(' + getIp() + ')')

Python脚本的功能如下：

• 获取外网ip地址。


• 获取域名解析记录。


• 新增域名解析记录。


• 更新域名解析记录。


• 删除域名解析记录 （并不建议将该功能添加在实际脚本中）。


• 批量操作，如果记录不存在则添加记录，存在则更新记录。

另外，有几点需要特别说明：

• 建议不要将删除记录添加进实际使用的脚本当中。


• 相同记录是同一个子域名的多条记录，比如 test.binghe.com。


• 脚本并没有验证记录类型，所以同一子域名下的不同类型的记录也会认为是相同记录，比如：有两条记录分别是 test.binghe.com 的 A 记录 和 test.binghe.com 的 AAAA 记录，会被认为是两条相同的 test.binghe.com 记录.如果需要判定为不同的记录，小伙伴们可以根据上述Python脚本自行实现。


• 可以通过判断获取记录返回的 record_id 来实现精确匹配记录。

最后，可以将以上脚本保存为文件之后，通过定时任务，来实现定期自动更新ip地址。

引言

在我们日常浏览网页的时候，通常会看到各种各样的内容，如文字、图片、视频等。这些内容背后都有一个共同的语言，那就是HTML（超文本标记语言）。HTML是构建网页的基础，它就像建筑物的框架，决定了网页的基本结构和布局。

然而，仅仅有结构是不够的。如果网页只是简单地用一些基础标签堆砌而成，那么浏览器、搜索引擎甚至我们自己在后期维护时，都会感到非常吃力。

这时候，HTML的语义化标签就显得尤为重要。语义化标签不仅能使网页结构更加清晰，还能帮助搜索引擎更好地理解和索引网页内容。

什么是HTML语义化标签？

HTML语义化标签，就是那些带有特定含义的标签，它们告诉浏览器和搜索引擎，每一部分内容是什么。这就好比是给每个内容部分都贴上了一个清晰的标签，让所有人都能明白这个部分是用来做什么的。

举个例子，假设你在看一本书，书的封面、目录、章节标题等都是明确标示出来的，这样你就能快速找到自己想看的部分。同样，HTML语义化标签也是为了让网页的内容更加明晰易懂。比如：

• <header> 标签用来定义网页的头部内容，通常包含导航栏、Logo等信息；


• <nav> 标签专门用于定义导航链接，这样搜索引擎就能更好地理解网站的结构；


• <article> 标签用于定义独立的内容，比如一篇新闻文章或者博客帖子。


• ……

通过使用这些语义化标签，不仅提高了网页的可读性和维护性，还能帮助搜索引擎更准确地抓取和排名内容，从而提升网站的SEO效果。

为什么使用语义化标签？

使用HTML语义化标签有很多好处，它们不仅能让代码更清晰，还能带来实际的效果和便利。

另外不得不说，目前苹果对语义化标签的使用是最炉火纯青的。怪不得都说苹果优雅，现在算是在前端上见识到了这个细节怪……

其实还有很多大厂都在使用，但都是偷偷地使用。它们没有全局使用语义化标签，而是在特定的关键位置使用语义化标签来 “谄媚” 一下搜索引擎或浏览器提供的无障碍功能。

所以我相信很多人还是非常支持div一把梭的，只要老板不限制，想怎么做就怎么做。不过如果你也能学习大厂，在漫天div下加一点语义化标签的小巧思，骗过搜索引擎和浏览器，这不是很香吗？

所以，本文着重介绍那些搜索引擎和浏览器有特别支持的语义化标签，搞定他们就搞定了一大半！

常用的语义化标签

搜索引擎钟爱的语义化标签

搜索引擎（如Google、Bing等）特别关注某些HTML语义化标签，因为这些标签能够帮助它们更好地理解网页的结构和内容，从而改进搜索结果的质量。

以下是一些被搜索引擎特别关注的语义化标签：

浏览器的无障碍功能

现代浏览器具备许多无障碍功能（accessibility features），这些功能可以帮助有特殊需求的用户更好地浏览网页。

以下是一些关键的无障碍功能：

语义化标签的实际应用

为了更好地理解语义化标签的使用方法，让我们通过一个具体的案例来展示它们的实际应用。

假设我们要创建一个简单的博客页面，包含标题、导航栏、文章内容、侧边栏和页脚。下面是一个示例代码：

<!DOCTYPE html>

<html lang="zh-CN">

<head>

    <meta charset="UTF-8">

    <title>我的博客</title>

    <style>

        body { font-family: Arial, sans-serif; }

        header, nav, article, aside, footer { margin: 20px; padding: 10px; border: 1px solid #ccc; }

        nav ul { list-style-type: none; padding: 0; }

        nav ul li { display: inline; margin-right: 10px; }

        aside { float: right; width: 30%; }

        article { float: left; width: 65%; }

    </style>

</head>

<body>

    <header>

        <h1>我的博客</h1>

        <nav>

            <ul>

                <li><a href="#home">首页</a></li>

                <li><a href="#about">关于我</a></li>

                <li><a href="#contact">联系我</a></li>

            </ul>

        </nav>

    </header>

    <section>

        <article>

            <h2>文章标题</h2>

            <p>这里是文章的正文内容。</p>

        </article>

        <aside>

            <h2>侧边栏</h2>

            <p>这里是一些附加内容，比如广告或链接。</p>

        </aside>

    </section>

    <footer>

        <p>版权所有 Dikkoo; 2024 我的博客</p>

    </footer>

</body>

</html>

回顾一下

在这个案例中，我们使用了多个语义化标签来组织页面内容：

• <header> 包含网站的标题和导航栏。


• <nav> 用于定义导航链接区域。


• <section> 用于分隔主要内容区域，包含文章和侧边栏。


• <article> 定义了独立的文章内容。


• <aside> 包含附加内容，如侧边栏。


• <footer> 包含页面的底部信息。

怎样合理运用语义化标签？

为了充分发挥HTML语义化标签的优势，以下是一些最佳实践建议：

今天，五阳哥不打算聊技术，而是聊一下炒股的话题。我自认为在这方面有发言权，自述一个程序员的炒股经历。

2019年，我开始涉足股市，在2021年中旬为了购房，将持有的股票全部卖出，赚了十多万元。在最高峰时期，我获利超过了二十多万元，但后来又回吐了一部分利润。虽然我的炒股成绩不是最出色的，但也超过了很多人。因为大多数股民都是亏损的，能够在股市长期盈利的人真的是凤毛麟角。

股市中普遍流传的七亏二平一赚的说法并不只是传闻，事实上，现实中的比例更加残酷，能够长期赚钱的人可能连10%都达不到。

接下来，我想谈谈我的炒股经历和心路历程，与大家分享一下我的内心体验，为那些有意向或正在炒股的朋友提供一些参考。希望劝退大家，能救一个是一个！

本文倒叙描述，先聊聊最后的疯狂和偏执！

不甘失败，疯狂上杠杆

股市有上涨就有下跌，在我卖出以后，股市继续疯涨了很多。当时长春高新，我是四百一股买入，六百一股就卖出了，只赚了2万。可是在我卖出去的两个月以后，它最高涨到了一千。相当于我本可以赚六万，结果赚了两万就跑了。

我简直想把大腿拍烂了，这严重的影响了我的认知。我开始坚信，这只股票和公司就是好的，非常牛，是我始乱终弃，我不应该早早抛弃人家。 除了悔恨，我还在期盼它下跌，好让我再次抄底，重新买入，让我有重新上车的机会！

终于这只股票后来跌了10%，我觉得跌的差不多了，于是我开始抄底买入！抄底买入的价格在900一股（复权前）。

没想到，这次抄底是我噩梦的开始。我想抄他的底，他想抄我的家！

这张图，完美的诠释了我的抄底过程。地板底下还有底，深不见底，一直到我不再敢抄底为止。一直抄到，我天天睡不着觉！

当时我九百多一股开始抄底买入，在此之前我都是100股，后来我开始投入更多的资金在这只股票上。当时的我 定下了规矩，鸡蛋不能放在一个篮子里；不能重仓一只股票，要分散投资；这些道理我都明白，但是真到了节骨眼上，我不想输，我想一把赢回来，我要抄底，摊平我的成本。

正所谓：高位加仓，一把亏光。之前我赚的两万块钱，早就因为高位加仓，亏回去了。可是我不甘心输，我想赢回来。当时意识不到也不愿意承认：这就是赌徒心理。

后来这只股票，从1000，跌倒了600，回调了40%。而我已经被深深的套牢。当时我盈利时，只买了1股。等我被套牢时，持有了9股。 按照1000一股，就是九十万。按照600一股，就是54万。

我刚毕业，哪来的那么多钱！

我的钱，早就在800一股的时候，我就全投进去了，我认为800已经算是底了吧，没想到股价很快就击穿了800。

于是我开始跟好朋友借钱。一共借了10万，商量好借一年，还他利息。后来这10万块钱，也禁不住抄底，很快手里没钱了，股价还在暴跌。我已经忘记当时亏多少钱了，我当时已经不敢看账户了，也不敢细算亏了多少钱！

于是，我又开始从支付宝和招商银行借贷，借钱的利率是相当高的，年利息在6%以上。当时一共借了30万。但是股价还不见底，我开始焦虑的睡不着觉。

不光不见底，还在一直跌，我记得当时有一天，在跌了很多以后，股价跌停 -10%。当时的我已经全部资金都投进去了，一天亏了5万，我的小心脏真的要受不了了。跌的我要吐血！ 同事说，那天看见我的脸色很差，握着鼠标手还在发抖！

跌成这样，我没有勇气打开账户…… 我不知道什么时候是个头，除了恐惧只有恐惧，每天活在恐惧之中。

我盘算了一下，当时最低点的我，亏了得有二十多万。从盈利六万，一下子到亏二十多万。只需要一个多月的时间。

我哪里经历过这些，投资以来，我都是顺风顺水的，基本没有亏过钱，从来都是挣钱，怎么会成这个样子。

当时的我，没空反思，我只希望，我要赚回来！我一定会赚回来，当时能借的支付宝和招行都已经借到最大额度了…… 我也没有什么办法了，只能躺平。

所以股价最低点的时候，基本都没有钱加仓。

侥幸反弹，但不忍心止盈

股价跌了四个月，这是我人生极其灰暗的四个月。后来因为种种原因，股价涨回来了，当时被传闻的事情不攻自破，公司用实际的业绩证明了自己。

股价开始慢慢回暖，后来开始凶猛的反弹，当时的��一直认为：股价暴跌时我吃的所有苦，所有委屈，我都要股市给我补回来！

后来这段时间，股价最高又回到了1000元一股（复权前）。最高点，我赚了二十多万，但是我不忍心止盈卖出。

我觉得还会继续涨，我还在畅想：公司达到，万亿市值。

我觉得自己当时真的 失了智了。

结婚买房，卖在最高点

这段时间，不光股市顺丰顺水，感情上也比较顺利，有了女朋友，现在是老婆了。从那时起，我开始反思自己的行为，我开始意识到，自己彻彻底底是一个赌徒。

因为已经回本了，也赚了一点钱，我开始不断的纠结要不要卖出，不再炒股了。

后来因为两件事，第一件是我姐姐因为家里要做小买卖，向我借钱。 当时的我，很纠结，我的钱都在股市里啊，借她钱就得卖股票啊，我有点心疼。奈何是亲姐，就借了。

后来我盘算着，不对劲。我还有贷款没还呢，一共三十万。我寻思，我从银行借钱收6%的利息，我借给别人钱，我一分利息收不到。 我TM 妥妥的冤大头啊。

不行，我要把贷款全部还上，我Tm亏大了，于是我逐渐卖股票。一卖出便不可收拾。

我开始担心，万一股价再跌回去，怎么办啊。我和女朋友结婚时，还要买房，到时候需要一大笔钱，万一要是被套住了，可怎么办啊！

在这这样的焦虑之下，我把股票全部都卖光了！

冥冥之中，自有天意。等我卖出之后的第二周，长春高新开启了下一轮暴跌，而这一轮暴跌之后，直至今日，再也没有翻身的机会。从股价1000元一股，直至今天 300元一股（复权前是300，当前是150元）。暴跌程度大达 75%以上！

全是侥幸

我觉得我是幸运的，如果我迟了那么一步！假如反应迟一周，我觉得就万劫不复。因为再次开启暴跌后，我又会开始赌徒心理。

我会想，我要把失去的，重新赢回来！我不能现在卖，我要赢回来。再加上之前抄底成功一次，我更加深信不疑！

于是我可能会从1000元，一路抄底到300元。如果真会如此，我只能倾家荡产！

不是每个人都有我这么幸运，在最高点，跑了出去。 雪球上之前有一个非常活泼的用户， 寒月霖枫，就是因为投资长春高新，从盈利150万，到亏光100万本金，还倒欠银行！

然而这一切，他的家人完全不知道，他又该如何面对家人，如何面对未来的人生。他想自杀，想过很多方式了结。感兴趣的朋友可以去 雪球搜搜这个 用户，寒月霖枫。

我觉得 他就是世界上 另一个自己。我和他完全类似的经历，除了我比他幸运一点。我因为结婚买房和被借钱，及时逃顶成功，否则我和他一样，一定会输得倾家荡产！

我觉得，自己就是一个赌狗！

然而，在成为赌狗之前，我是非常认真谨慎对待投资理财的！

极其谨慎的理财开局

一开始，我从微信理财通了解到基金，当时2019年，我刚毕业两年，手里有几万块钱，一直存在活期账户里。其中一个周末，我花时间研究了一下理财通，发现有一些债券基金非常不错。于是分几批买了几个债券基金，当时的我对于理财既谨慎又盲目。

谨慎的一面是：我只敢买债券基金，就是年利息在 5%上下的。像股票基金这种我是不敢买的。

盲目的一面是：我不知道债券基金也是风险很大的，一味的找利息最多的债券基金。

后来的我好像魔怔了，知道了理财这件事，隔三差五就看看收益，找找有没有利息更高的债券基金。直到有一天，我发现了一个指数基金，收益非常稳定。

是美股的指数基金，于是我买了1万块钱，庆幸的是，这只指数基金，三个月就赚了八百多，当时的我很高兴。那一刻，我第一次体会到：不劳而获真的让人非常快乐！

如饥似渴的学习投资技巧

经过一段时间的理财，我对于理财越来越熟悉。

胆子也越来越大，美股的指数基金赚了一点钱，我害怕亏回去，就立即卖了。卖了以后就一直在找其他指数基金，这时候我也在看国内 A股的指数基金，甚至行业主题的基金。

尝到了投资的甜头以后，我开始花更多的时间用来 找基。我开始从方方面面评估一只基金。

有一段时间，我特别自豪，我在一个周末，通过 天天基金网，找到了一个基金，这只基金和社保投资基金的持仓 吻合度非常高。当时的我思想非常朴素， 社保基金可是国家队，国家管理的基金一定非常强，非常专业，眼光自然差不了。这只基金和国家队吻合度如此高，自然也差不了。

于是和朋友们，推荐了这只基金。我们都买了这只基金，而后的一个月，这只基金涨势非常喜人，赚了很多钱，朋友们在群里也都感谢我，说我很厉害，投资眼光真高！

那一刻，我飘飘然……

我开始投入更多的时间用来理财。下班后，用来学习的时间也不学习了，开始慢慢的过度到学习投资理财。我开始不停地 找基。当时研究非常深入，我会把这只基金过往的持仓记录，包括公司都研究到。花费的时间也很多。

我也开始看各种财经分析师对于股市的分析，他们会分析大盘何时突破三千点，什么时候股市情绪会高昂起来，什么行业主题会热门，什么时候该卖出跑路了。

总之，投资理财，可以学习的东西多种多样！似乎比编程有趣多了。

换句话说：我上头了

非常荒谬的炒股开局

当时我还是非常谨慎地，一直在投资基金，包括 比较火爆的 中欧医疗创新C 基金，我当时也买了。当时葛兰的名气还很响亮呢。后来股市下行，医疗股票都在暴跌，葛兰的基金 就不行了，有句话调侃：家里有钱用不完，中欧医疗找葛兰。腰缠万贯没人分，易方达那有张坤。

由此可见，股市里难有常胜将军！

当时的我，进入股市，非常荒谬。有一天，前同事偷偷告诉我，他知道用友的内幕，让我下午开盘赶紧买，我忙追问，什么内幕，他说利润得翻五倍。 我寻思一下，看了一眼用友股票还在低位趴着，心动了。于是我中午就忙不迭的线上开户，然后下午急匆匆的买了 用友。 事后证明，利润不光没有翻五倍，还下降了。当然在这之前，我早就跑了，没赚着钱，也没咋亏钱。

当时的我，深信不疑这个假的小道消息，恨不得立即买上很多股票。害怕来不及上车……

自从开了户，便一发不可收拾，此时差2个月，快到2019年底！席卷全世界的病毒即将来袭

这段时间，股市涨势非常好，半导体基金涨得非常凶猛！ 我因为初次进入股市，没有历史包袱，哪个股票是热点，我追哪个，胆子非常大。而且股市行情非常好，我更加相信，自己的炒股实力不凡！

换句话说：越来越上头，胆子越来越大。 学习编程，学个屁啊，炒股能赚钱，还编个屁程序。

刚入股市，就赶上牛市，顺风顺水

2019年底到2020年上半年，A股有几年不遇的大牛市，尤其是半导体、白酒、医疗行业行情非常火爆。我因为初入股市，没有历史包袱，没有锚点。当前哪个行业火爆，我就买那个，没事就跑 雪球 刷股票论坛的时间，比上班的时间还要长。

上班摸鱼和炒股 是家常便饭。工作上虽然不算心不在焉，但是漫不经心！

在这之前，我投入的金额不多。最多时候，也就投入了10万块钱。当时基金收益达到了三万块。我开始飘飘然。

开始炒股，也尝到了甜头，一开始，我把基金里的钱，逐渐的转移到股市里。当时的我给自己定纪律。七成资金投在基金里，三成资金投在股市里。做风险平衡，不能完全投入到风险高的股市里。

我自认为，我能禁得住 炒股这个毒品。

但是逐渐的，股票的收益越来越高，这个比例很快就倒转过来，我开始把更多资金投在股市中，其中有一只股票，我非常喜欢。这只股票后来成为了很多人的噩梦，成为很多股民 人生毁灭的导火索！

长春高新 股票代码：000661。我在这只股票上赚的很多，后来我觉得股市涨了那么多，该跌了吧，于是我就全部卖出，清仓止盈。 当时的我利润有六万，我觉得非常多了，我非常高兴。

其中 长春高新 一只股票的利润在 两万多元。当时这是我最喜欢的一只股票。我做梦也想不到，后来这只股票差点让我倾家荡产……

当时每天最开心的事情就是，打开基金和证券App，查看每天的收益。有的时候一天能赚 两千多，比工资还要高。群里也非常热闹，每个人都非常兴奋，热烈的讨论哪个股票涨得好。商业互吹成风……

换句话说：岂止是炒股上头，我已经中毒了！

之后就发生了，上文说的一切，我在抄底的过程中，越套越牢……

总结

以上都是我的个人真实经历。 我没有谈 A 股是否值得投资，也不评论当前的股市行情。我只是想分享自己的个人炒股经历。

炒股就是赌博

我想告诉大家，无论你在股市赚了多少钱，迟早都会还回去，越炒股越上头，赚的越多越上头。

赌徒不是一天造成的，谁都有赢的时候，无论赚多少，最终都会因为人性的贪婪 走上赌徒的道路。迟早倾家荡产。即使你没有遇到长春高新，也会有其他暴跌的股票等着你！

什么🐶皮的价值投资！ 谈价值投资，撒泡尿照照自己，你一个散户，你配吗？

漫漫人生路，总会错几步。股市里错几步，就会让你万劫不复！

”把钱还我，我不玩了“

”我只要把钱赢回来，我就不玩了“

这都是常见的赌徒心理，奉劝看到此文的 程序员朋友，千万不要炒股和买基金。

尤其是喜欢打牌、打德州扑克，喜欢买彩-票的 赌性很强的朋友，一定要远离炒股，远离投资！

能救一个是一个！

为何要扒

因为最近有移动端业务的需求，用uniapp做了ios、Android双端的app应用，由于没有资质上架AppStore和test flight，所以只能使用苹果的超签（需要ios用户提供uuid才能加入测试使用，并且只支持100人安装使用）。打包出来生成的是一个ipa包，并不能直接安装，要通过爱思助手这类的应用装一下ipa包。但交付到客户手上就有问题了，还需要电脑连接助手才能安装，那岂不是每次安装新版什么的，都要打开电脑搞一下。因此，才有了这次的扒一扒，目标就是为了解决只提供一个下载链接用户即可下载，不用再通过助手类应用安装ipa包。

开干

官方模板

先打开uniapp云打包一下项目看看

复制地址到移动端浏览器打开看看

这就对味了，都知道ios是不能直接打开ipa文件进行安装的，接下来就研究下这个页面的执行逻辑。

开扒

F12打开choromdevtools，ctrl+s保存网页html。

保存成功，接下来看看html代码(样式代码删除了)

    <!DOCTYPE html>

<!-- saved from url=(0077)https://ide.dcloud.net.cn/build/download/2425a4b0-4229-11ee-bd1b-67afccf2f6a7 -->

<html>

    <head>

        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

        <meta name="viewport" content="initial-scale=1.0, maximum-scale=1.0, user-scalable=no, width=device-width">

        <meta name="apple-mobile-web-app-capable" content="yes">

        <meta name="apple-mobile-web-app-status-bar-style" content="black">

  </head>

​

<body>

<br><br>

    <center>

        <a class="button" href="itms-services://?action=download-manifest&amp;url=https://ide.dcloud.net.cn/build/ipa-xxxxxxxxxxx.plist">点击安装</a>

    </center>

    <br><br>

    <center>注意:只提供包名为io.dcloud.appid的包的直接下载安装，如果包名不一致请自行搭建下载服务器</center>

</body>

</html>

解析

从上面代码可以看出，关键代码就一行也就是a标签的href地址（"itms-services://?action=download-manifest&url=ide.dcloud.net.cn/build/ipa-x…"）

先看看itms-services是什么意思，下面是代码开发助手给的解释

大概意思就是itms-services是苹果提供给开发者一个的更新或安装应用的协议，用来做应用分发的，需要指向一个可下载的plist文件地址。

什么又是plist呢，这里再请我们的代码开发助手解释一下

对于没接触过ios相关开发的，连plist文件怎么写都不知道，既然如此，那接下来就来扒一下dcloud的pilst文件，看看官方是怎么写的吧。

打开浏览器，copy一下刚刚扒下来的html文件下a标签指向的地址，复制url后面plist文件的下载地址粘贴到浏览器保存到桌面。

访问后会出现

别担心，这时候直接按ctrl+s可以直接保存一个plist.xml文件，也可以打开devtools查看网络请求，找到ipa开头的请求

直接新建一个plist文件，cv一下就好，我这里就选择保存它的plist.xml文件，接下来康康文件里到底是什么

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

    <key>items</key>

    <array>

        <dict>

            <key>assets</key>

            <array>

                <dict>

                    <key>kind</key>

                    <string>software-package</string>

                    <key>url</key>

                    <string>https://bdpkg-aliyun.dcloud.net.cn/20230824/xxxxx/Pandora.ipa?xxxxxxxx</string>

                </dict>

                   <dict>

                    <key>kind</key>

                    <string>display-image</string>

                    <key>needs-shine</key>

                    <false/>

                    <key>url</key>

                    <string>https://qiniu-web-assets.dcloud.net.cn/unidoc/zh/uni.png</string>

                </dict>

            </array>

            <key>metadata</key>

            <dict>

                <key>kind</key>

                <string>software</string>

                <key>bundle-identifier</key>

                <string>xxxxx</string>

                <key>title</key>

                <string>HBuilder手机应用</string>

            </dict>

        </dict>

    </array>

</dict>

</plist>

直接抓重点，这里存你存放ipa包的地址

这里改你应用的昵称

这里改图标

因篇幅限制，想了解plist的自行问代码助手或者搜索引擎。

为我所用

分析完了，如何为我所用呢，首先按照分析上扒下来的plist文件修改下自身应用的信息，并且需要服务器存放ipa文件，这里我选择了unicloud，开发者可以申请一个免费的空间（想了解更多的自己去dcloud官网看看，说多了有打广告嫌疑），替换好大概如下：

将plist文件放到服务器上后，拿到plist的下载地址，打开扒下来的html，将a标签上的url切换成plist文件的下载地址，如图：

可以把页面上没用的信息都删掉，保存，再把html放到服务器上，用户访问这个地址，就可以直接下载描述文件安装ipa包应用了（记得需要添加用户的uuid到开发者账号上），其实至此需求已经算是落幕了，但转念想想还是有点麻烦，于是又优化了一下，将a标签中的href信息，直接加载到二维码上供用户扫描便可直接下载，相对来说更方便一点，于是我直接打开草料，生成了一个二维码，至此，本次扒拉过程结束，需求落幕！

最近发现比尔盖茨还在写文章，确实了不起，68 岁的老人家还在坚持输出，除了写文章，比尔盖茨还致力于教育、医疗和卫生等慈善工作，奋斗在一线，看来美国人也延迟退休啊 😅

原文《AI 将彻底改变计算机的使用方式》 大约一万多字，从宏观的角度讲述了 AI 的形态，并且提及了 AI 将影响的四个行业，最后再讲到目前面临的技术问题和非技术问题，整体文章深入浅出，非常值得一读。

本文做了一些删减，并尝试用自己的话去解读，更加符合中文读者的语义，其中的一些观点仅供参考，大家自由评判之，毕竟比尔先生还预测过计算机只需要 768kb 内存足以，而现在 8 个 G 都不够下饭的。

未来是智能体

首先比尔先生回忆了和保罗·艾伦一起创立微软公司的感觉，然后语重心长讲到，虽然经过了几十年的更迭，但是计算机还是比较蠢笨的，你要完成一个任务，得先选择某一个 app，比如用微软的 Word，去画一个商业的草图，但是这个 app 不能帮你发送邮件、分享自拍、分析数据、计划一个聚会，或者买电影票，要完成上述这些事情，要么找一个亲密的朋友，要么有一个个人助理。

胆大的预测，在下一个五年，AI 将彻底重构，你不需要再用为了处理不同任务，而去使用不同的 app。你可以用任何语言，直接告诉你的设备，你想要做什么。AI 借由丰富的理解能力，为你做个性化的服务和响应。在不远的将来，每个人都能够拥有远超当前科技的个性化的人工智能助手。

这种软件形态，比尔先生思考了 30 多年，但是最近两年来才成为现实，这种形态叫做“智能体”（Agent），能够用自然语言回复，并且基于用户的背景知识去完成不同的任务。

智能体不只是改变每个人和计算机的交互，他们同样颠覆了整个软件工业，这是从命令行输入、图形化交互以来，计算机交互最大的变革。

这里就可以总结了，比尔先生认同「All in One」的观点，一个智能体，处理你的一切事务，并且用发展的眼光看待，在之后技术继续蓬勃发展，智能体将登基，成为新的软件形态之主。

区分机器人和智能体

现在很多公司，做出来的产品根本算不上智能体，只能叫做机器人（Bot），机器人内嵌在某一个 app，借由 AI 的能力处理一些特定的任务，比如文本润色、扩写等，他们不会记住你用过多少次，也不会记住你的喜好，只能冰冷冷的机器人。

智能体不一样，更聪明，更主动，在你询问它们意见之前，就能够给到你合适的建议。它们能够跨 app 处理任务，记录你的行为，识别你的动机和意图，随着时间的推移，它们会慢慢变得更好，更加准确的给你提供信息和建议。

举个例子 🌰，你想要来一场特种兵旅行，机器人只能根据你的预算，给你定位酒店。而智能体，了解你近年来的旅行资料，能够推断出你是想要找一个距离景点近一点的还是远一点的，来为你推荐合适的酒店，还能根据你的兴趣和倾向，为你规划行程、预定餐厅。

AI 智能体，还有最让人激动的能力，那就把现在一些昂贵的服务价格给打下来，在这四个领域中，医疗健康、教育、生产力以及娱乐购物，智能体将大展拳脚。

医疗健康

目前，AI 的作用局限于处理一些非医疗任务，比如，就诊时候录音，然后生成报告给医生检查回顾。接下来会真正的转变，智能体能够帮助病人去做一个基础的伤病分类，获取关于处理健康问题的建议，决定是否需要去做进一步治疗。这些智能体还能够帮助医疗人员做决定，使之更加的高效。

现在已经有类似的 app 了，比如 Glass Health，能够分析病人摘要、提供建议诊断给医生做参考。

有了这些帮助病人和医疗人员的智能体，才是真正利于处在贫困的国家地区，那些贫瘠地方的老百姓们，甚至从来都没见过医生。比尔先生大义 🫡

这类「临床医学智能体」普及的速度可能会比较慢，毕竟这事关生死。人们需要看到这些健康智能体真正起到作用的证据，才能够接受它们。虽然健康智能体可能不完美，会犯错，但是，人类也同样不完美，会犯错。

教育

十多年来，比尔先生一直对借助软件帮助学生学习、让老师工作更轻松这样的事情很上心，软件不会替代教师工作，它只能对他们的工作进行补充，比如对学生做到个性化教育，从批改作业的压力中解放，还有其他种种。

现在已经有初步的进展，那就是一些基于文本的教育智能体，他们能够解释二元方程、提供练习数学题等等，但这还仅仅只是初步能力，接下来智能体还会解锁更多的能力。

确实，AI 学习辅导这个需求确实不错，之前热搜有这么一个家长给孩子辅导的问题

通过 AI 可以给到很好的学习启发：

生产力

生产力这方面已经卷得飞起了，微软以及为 Word、Outlook 等其他 app 集成了 Copilot（副驾驶），谷歌也在做类似的事情，也把 Bard 集合在自家的生产力 app 中。这些 Copilot 可以做很多事情，比如把文本转换为 PPT，回答表格问题，总结电子邮件内容等等。

当然，智能体能做到还有更多，如果你有一个商业想法，智能体会做一份商业计划书，然后基于此创建一份展示汇报，还能根据你的内容插入生成合适的图片。

娱乐购物

好吧，AI 可能帮你挑选电视频道、推荐电影、书、电视剧等等。比如，最近比尔盖茨投资了一家创业公司 Pix，用问答的方式推荐电影。虾皮也有一个基于 AI 的「DJ」，它能够根据你的喜好播放歌曲，并且还能和你交流，甚至会喊你的名字。

对科技行业的冲击波

总而言之，智能体最终能够帮助到我们生活的方方面，这对整个软件行业和社会的影响将会是深远的。

在计算领域，我们常谈论的「平台」，比如安卓、iOS 还有 Windows，是目前 app 和服务赖以存在的基础，而智能体将会成为下一个平台。

创建一个 app 或者服务，你不需要知道如何如变成或者图形设计，你只需要告诉你的智能体你想要做什么，它就能够编码、设计界面、创建 logo，然后发布到 app 到在线商店上，OpenAI 的 GPTs 能让我们一窥未来，GPTs 可以让非开发人员创建并分享自己的的智能体。

推荐下 starflow.tech，可以直接体验 GPTs

没有哪一家公司可以垄断智能体生意，因为未来会有多款不同 AI 引擎可供使用。现在，智能体只能依赖于其他软件，比如 Word 和 Excel，但是最终，他们将会独立运行。现在他们可能是免费的，但以后，你会为这些聪明高效的智能体付费，那么商业逻辑将改变，公司不再需要迎合广告公司而恶心用户，而是真正地为用户量身打造智能体。

在这些聪明但又复杂的智能体落地成为现实之前，还有大量的技术问题需要解决。

技术挑战

至今还没有人搞清楚智能体的底层存储结构是怎么样的，要创建一个个性化的智能体，我们需要一种新型数据库，它能把记录你的兴趣和关系的微妙之处，在保障隐私的情况下还能够快速查询信息。目前向量数据库是一种，或许之后还会有其他更好的呢。

另一个开放的问题就是一个用户大概需要和多少智能体打交道呢？你的个性化智能体会被分为医疗智能体和数学教师智能体吗？如果是的话，你是希望这些智能体彼此能够协作，还是在各自领域保持独立？

智能体的形态会是怎么样的呢，是手机、眼睛、项链、徽章，甚至是全息投影？这里比尔先生推测，现阶段最适合的是耳机，它能够听取你的声音，然后通过耳机回复你，其他的好处是，它还能调节音量、屏蔽周围噪音。

这里面还有其他种种技术挑战存在

1️⃣ 智能体之间互相交流的标准协议？

2️⃣ 智能体的价格要怎么打到每个人都能够用得起？

3️⃣ 用户少量提示词和智能体的准确回复之间如何取得平衡？

4️⃣ 如何减少幻觉，特别是在医疗这种特别重要的场景下？

5️⃣ 如何确保智能体不会伤害 or 歧视人类？

6️⃣ 如何确保智能体不会越权进行犯罪？

在不远的将来，智能体会迫使人类去思考，我们这么做是为了什么？想象一下，一个足够优秀的智能体存在，我们基本不需要工作了，那么每个人还需要接受高水平的教育吗？在未来可能是这样的，人们怎么消磨他们的时间？在所有答案都是已知的情况下，每个人还想要去上学吗？每个人都有大量的空闲时间，你还能有一个安全和繁荣的社会吗？

不过到这个时间点还很早，但至少目前，智能体正在走来，在接下来的几年，他们将彻底改变我们的生活。

"```markdown
每次页面加载时清除本页缓存可以通过多种方式实现，具体方法取决于需要的粒度和数据类型。以下是一些常见的技术：

使用meta标签（HTML）：

<meta http-equiv=\"cache-control\" content=\"no-cache, no-store, must-revalidate\">

<meta http-equiv=\"pragma\" content=\"no-cache\">

<meta http-equiv=\"expires\" content=\"0\">

使用JavaScript：

// 清除整个页面缓存

window.location.reload(true);



// 清除特定资源的缓存

const url = 'https://example.com/style.css';

fetch(url, {

  headers: {

    'Cache-Control': 'no-cache, no-store, must-revalidate',

    'Pragma': 'no-cache',

    'Expires': '0'

  }

}).then(response => {

  // 处理响应

});



// 清除localStorage

localStorage.clear();



// 清除sessionStorage

sessionStorage.clear();

使用HTTP头信息（服务端设置）：

// Express.js 示例

app.use((req, res, next) => {

  res.setHeader('Cache-Control', 'no-cache, no-store, must-revalidate');

  res.setHeader('Pragma', 'no-cache');

  res.setHeader('Expires', '0');

  next();

});

使用框架或库功能：

例如，React中可以通过key属性强制重新渲染组件来清除缓存：

function App() {

  const [key, setKey] = useState(0);



  const resetPage = () => {

    setKey(prevKey => prevKey + 1);

  };



  return (

    <div key={key}>

      {/* 页面内容 */}

      <button onClick={resetPage}>重置页面</button>

    </div>

  );

}

清除浏览器缓存：

用户可以手动清除浏览器缓存来达到相同的效果。这通常通过浏览器设置或开发者工具的Network面板来实现。

综上所述，实现每次页面加载时清除本页缓存可以根据具体情况选择合适的方法。无论是通过HTML标签、JavaScript代码、服务器端设置还是框架功能，都可以有效地控制和管理页面的缓存行为，确保用户获得最新和最准确的内容。

在业务开发的时候，经常会遇到某一个接口不能对外暴露，只能内网服务间调用的实际需求。

面对这样的情况，我们该如何实现呢？

1. 内外网接口微服务隔离

将对外暴露的接口和对内暴露的接口分别放到两个微服务上，一个服务里所有的接口均对外暴露，另一个服务的接口只能内网服务间调用。

该方案需要额外编写一个只对内部暴露接口的微服务，将所有只能对内暴露的业务接口聚合到这个微服务里，通过这个聚合的微服务，分别去各个业务侧获取资源。

该方案，新增一个微服务做请求转发，增加了系统的复杂性，增大了调用耗时以及后期的维护成本。

2. 网关 + redis 实现白名单机制

在 redis 里维护一套接口白名单列表，外部请求到达网关时，从 redis 获取接口白名单，在白名单内的接口放行，反之拒绝掉。

该方案的好处是，对业务代码零侵入，只需要维护好白名单列表即可；

不足之处在于，白名单的维护是一个持续性投入的工作，在很多公司，业务开发无法直接触及到 redis，只能提工单申请，增加了开发成本；

另外，每次请求进来，都需要判断白名单，增加了系统响应耗时，考虑到正常情况下外部进来的请求大部分都是在白名单内的，只有极少数恶意请求才会被白名单机制所拦截，所以该方案的性价比很低。

3. 方案三 网关 + AOP

相比于方案二对接口进行白名单判断而言，方案三是对请求来源进行判断，并将该判断下沉到业务侧。避免了网关侧的逻辑判断，从而提升系统响应速度。

我们知道，外部进来的请求一定会经过网关再被分发到具体的业务侧，内部服务间的调用是不用走外部网关的（走 k8s 的 service）。

根据这个特点，我们可以对所有经过网关的请求的header里添加一个字段，业务侧接口收到请求后，判断header里是否有该字段，如果有，则说明该请求来自外部，没有，则属于内部服务的调用，再根据该接口是否属于内部接口来决定是否放行该请求。

该方案将内外网访问权限的处理分布到各个业务侧进行，消除了由网关来处理的系统性瓶颈；

同时，开发者可以在业务侧直接确定接口的内外网访问权限，提升开发效率的同时，增加了代码的可读性。

当然该方案会对业务代码有一定的侵入性，不过可以通过注解的形式，最大限度的降低这种侵入性。

具体实操

下面就方案三，进行具体的代码演示。

首先在网关侧，需要对进来的请求header添加外网标识符: from=public

@Component

public class AuthFilter implements GlobalFilter, Ordered {

    @Override

    public Mono < Void > filter ( ServerWebExchange exchange, GatewayFilterChain chain ) {

         return chain.filter(

         exchange.mutate().request(

         exchange.getRequest().mutate().header('id', '').header('from', 'public').build())

         .build()

         )；

    }



    @Override

    public int getOrder () {

        return 0;

    }

 }

接着，编写内外网访问权限判断的AOP和注解

@Aspect

@Component

@Slf4j

public class OnlyIntranetAccessAspect {

 @Pointcut ( '@within(org.openmmlab.platform.common.annotation.OnlyIntranetAccess)' )

 public void onlyIntranetAccessOnClass () {}

 @Pointcut ( '@annotation(org.openmmlab.platform.common.annotation.OnlyIntranetAccess)' )

 public void onlyIntranetAccessOnMethed () {

 }



 @Before ( value = 'onlyIntranetAccessOnMethed() || onlyIntranetAccessOnClass()' )

 public void before () {

     HttpServletRequest hsr = (( ServletRequestAttributes ) RequestContextHolder.getRequestAttributes()) .getRequest ();

     String from = hsr.getHeader ( 'from' );

     if ( !StringUtils.isEmpty( from ) && 'public'.equals ( from )) {

        log.error ( 'This api is only allowed invoked by intranet source' );

        throw new MMException ( ReturnEnum.C_NETWORK_INTERNET_ACCESS_NOT_ALLOWED_ERROR);

            }

     }

 }



@Target({ElementType.METHOD})

@Retention(RetentionPolicy.RUNTIME)

@Documented

public @interface OnlyIntranetAccess {

}

最后，在只能内网访问的接口上加上@OnlyIntranetAccess注解即可

@GetMapping ( '/role/add' )

@OnlyIntranetAccess

public String onlyIntranetAccess() {

    return '该接口只允许内部服务调用';

}

 4. 网关路径匹配 



在DailyMart项目中我采用的是第四种：即在网关中进行路径匹配。









该方案中我们将内网访问的接口全部以前缀/pv开头，然后在网关过滤器中根据路径找到具体校验器，如果是/pv访问的路径则直接提示禁止外部访问。















使用网关路径匹配方案不仅可以应对内网接口的问题，还可以扩展到其他校验机制上。

譬如，有的接口需要通过access_token进行校验，有的接口需要校验api_key 和 api_secret，为了应对这种不同的校验场景，只需要再实现一个校验类即可，由不同的子类实现不同的校验逻辑，扩展非常方便。

1.什么是pf4j?

一个插件框架，用于实现插件的动态加载，支持的插件格式（zip、jar）。

核心组件

• **Plugin：**是所有插件类型的基类。每个插件都被加载到一个单独的类加载器中以避免冲突。


• **PluginManager：**用于插件管理的所有方面（加载、启动、停止）。您可以使用内置实现作为JarPluginManager, ZipPluginManager, DefaultPluginManager（它是一个JarPluginManager+ ZipPluginManager），或者您可以从AbstractPluginManager（仅实现工厂方法）开始实现自定义插件管理器。


• **PluginLoader：**加载插件所需的所有信息（类）。


• **ExtensionPoint：**是应用程序中可以调用自定义代码的点。这是一个java接口标记。任何 java 接口或抽象类都可以标记为扩展点（实现ExtensionPoint接口）。


• **Extension：**是扩展点的实现。它是一个类上的 Java 注释

场景

有一个spring-boot实现的web应用，在某一个业务功能上提供扩展点，用户可以基于SDK实现功能扩展，要求可以管理插件，并且能够在业务功能扩展点处动态加载功能。

2.代码工程

实验目的

实现插件动态加载，调用 卸载

Demo整体架构

• pf4j-api：定义可扩展接口。


• pf4j-plugins-01：插件项目，可以包含多个插件，需要实现 plugin-api 中定义的接口。所有的插件jar包，放到统一的文件夹中，方便管理，后续只需要加载文件目录路径即可启动插件。


• pf4j-app：主程序，需要依赖 pf4j-api ，加载并执行 pf4j-plugins-01 。

pf4j-api

导入依赖

<dependency>

    <groupId>org.pf4j</groupId>

    <artifactId>pf4j</artifactId>

    <version>3.0.1</version>

</dependency>

自定义扩展接口，集成 ExtensionPoint ，标记为扩展点

package com.et.pf4j;



import org.pf4j.ExtensionPoint;



public interface Greeting extends ExtensionPoint {



    String getGreeting();



}

打包给其他项目引用

pf4j-plugins-01

如果你想要能够控制插件的生命周期，你可以自定义类集成 plugin 重新里面的方法

/*

 * Copyright (C) 2012-present the original author or authors.

 *

 * Licensed under the Apache License, Version 2.0 (the "License");

 * you may not use this file except in compliance with the License.

 * You may obtain a copy of the License at

 *

 *     http://www.apache.org/licenses/LICENSE-2.0

 *

 * Unless required by applicable law or agreed to in writing, software

 * distributed under the License is distributed on an "AS IS" BASIS,

 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

 * See the License for the specific language governing permissions and

 * limitations under the License.

 */

package org.pf4j.demo.welcome;



import com.et.pf4j.Greeting;

import org.apache.commons.lang.StringUtils;



import org.pf4j.Extension;

import org.pf4j.Plugin;

import org.pf4j.PluginWrapper;

import org.pf4j.RuntimeMode;



/**

 * @author Decebal Suiu

 */

public class WelcomePlugin extends Plugin {



    public WelcomePlugin(PluginWrapper wrapper) {

        super(wrapper);

    }



    @Override

    public void start() {

        System.out.println("WelcomePlugin.start()");

        // for testing the development mode

        if (RuntimeMode.DEVELOPMENT.equals(wrapper.getRuntimeMode())) {

            System.out.println(StringUtils.upperCase("WelcomePlugin"));

        }

    }



    @Override

    public void stop() {

        System.out.println("WelcomePlugin.stop()");

    }



    @Extension

    public static class WelcomeGreeting implements Greeting {



        @Override

        public String getGreeting() {

            return "Welcome ,my name is pf4j-plugin-01";

        }



    }



}

打成jar或者zip包，方便主程序加载

pf4j-app

加载插件包

package com.et.pf4j;



import org.pf4j.JarPluginManager;

import org.pf4j.PluginManager;

import org.springframework.boot.autoconfigure.SpringBootApplication;



import java.nio.file.Paths;

import java.util.List;



@SpringBootApplication

public class DemoApplication {



/* public static void main(String[] args) {

      SpringApplication.run(DemoApplication.class, args);

   }*/

   public static void main(String[] args) {





      // create the plugin manager

      PluginManager pluginManager = new JarPluginManager(); // or "new ZipPluginManager() / new DefaultPluginManager()"



      // start and load all plugins of application

      //pluginManager.loadPlugins();



      pluginManager.loadPlugin(Paths.get("D:\\IdeaProjects\\ETFramework\\pf4j\\pf4j-plugin-01\\target\\pf4j-plugin-01-1.0-SNAPSHOT.jar"));

      pluginManager.startPlugins();

      /*

        // retrieves manually the extensions for the Greeting.class extension point

        List<Greeting> greetings = pluginManager.getExtensions(Greeting.class);

        System.out.println("greetings.size() = " + greetings.size());

        */

      // retrieve all extensions for "Greeting" extension point

      List<Greeting> greetings = pluginManager.getExtensions(Greeting.class);

      for (Greeting greeting : greetings) {

         System.out.println(">>> " + greeting.getGreeting());

      }



      // stop and unload all plugins

      pluginManager.stopPlugins();

      //pluginManager.unloadPlugins();





   }

}

3.测试

运行DemoApplication.java 里面的mian函数，可以看到插件加载，调用以及卸载情况

4.引用

• pf4j.org/


• github.com/pf4j/pf4j-s…

前言

Hi 你好，我是东东拿铁，一个正在探索个人IP的后端程序员。

前一阵子，组里面悄悄地走了两个同事，大家对此讳莫如深，原因自然不言而喻，被裁员了。

虽然裁员这件事情，在各种媒体上已经见怪不怪。但是近几年，即使是在北京，所在的公司确实还没遇到过这个情况。

本以为裁员这件事只存在于快节奏的大城市，但真正发生发生在二线城市的时候，我还是觉着心里蛮不舒服的。

因为裁员这个事情，对于个体来说，影响的确不小。

经济影响，裁员对个人的第一个影响就是收入中断。别看程序员收入比其他行业可能高一些，但是收入断层的压力依然很大。如果有房贷、车贷，更是雪上加霜。

职业发展，失去当前职位对程序员的职业发展产生不小影响，长期失业会导致技术技能的滞后，特别是在快速发展的科技行业，技术更新换代迅速。最重要的是，即使是短期的空白期，也可能使程序员在寻找新工作时，简历上的gap year也可能被HR视为一个警示信号。

心理压力，被裁员或许会经历自我怀疑、焦虑和抑郁等情绪，尤其是如果他们认为裁员是因为自己技能不足或表现不佳。这种心理压力可能会进一步影响他们在新工作中的表现和求职过程中的自信心。

所以看到身边的同事走了，我心里认为这真的是一件很糟糕的事情，从个人角度看，我认为裁员是不应该发生的。

但事实上愿望与真相的确不符合，我们常常拒绝接受真相。因为接受真相意味着改变，而改变可能会带来痛苦。

但是认清客观规律，才能认清自己，接受自己，不要固守你对事物"应该"是什么样的看法 这将使你无法了解真实的情况。

裁员存在很久了

太阳底下无新鲜事，裁员潮这件事情，早就不是第一次了。客观来讲，裁员这件事是的确是符合客观规律的，我们先回顾前面几次大的裁员潮吧，挑三个来讲。

90年代国有企业改革

1987年确定了改革开放，改革开放初期，逐步推行市场化改革，打破计划经济体制。

许多国有企业效率低下，国有企业迎来改革，负债累累，生产过剩。为了提高经济效率，政府推行国有企业改革，裁减冗员、减少亏损企业数量。

叠加政策推动，1997年党的十五大提出“抓大放小”政策，即保留和发展大型国有企业，改制或关闭小型亏损企业。

2008年全球金融危机

2008年爆发的全球金融危机导致外需急剧下降，许多出口导向型企业受到重创，全球经济衰退。

企业利润下降，为了控制成本，许多企业不得不裁员。

危机暴露了中国经济过度依赖外需和低附加值产业的问题，促使政府推动经济结构调整。

2019年互联网行业的大量裁员潮

从2018年下半年开始，不少互联网公司的裁员就已经开始，百度、阿里、腾讯、京东等大企业更是成为人们关注的焦点。

那是像摩拜、滴滴、美团等互联网行业，都是靠大量烧钱进行维持的，由于长期烧钱，投资者热情散去，各路资本也变的谨慎了。

是的，其实互联网裁员潮2019年就已经逐步开始了，互联网行业经过10多年的高速发展，慢慢走向了平稳期，互联网红利期已经过去，资本寒冬到来。

裁员背后的规律

企业战略与内部因素

成本控制与财务压力
企业在面临财务压力时，裁员通常是首选的成本控制手段之一。

通过减少员工数量，企业可以直接降低工资支出和相关福利成本。尤其是在利润率下降或财务报表不佳时，裁员成为企业迅速改善财务状况的一种方式。

比如最近理想汽车大裁员，背后就是因为纯电市场推广不顺，销售目标不及预期。

战略转型与业务重组

企业在战略转型或业务重组过程中，往往会调整其人力资源配置。例如，当企业从传统业务转向新兴技术领域时，原有的一些岗位可能不再需要，从而导致裁员。又或者，企业合并或收购也会带来很多人员问题。

比如4月底，马斯克裁撤了整个超充团队，与企业的战略是相关的，欧美充电桩市场竞争很激烈，国内的超充体系技术革新也很快，特斯拉超充的竞争力明显减弱，其实主要就是盈利问题吧。

效率提升与自动化

随着技术的进步，企业会不断寻求通过自动化和技术创新来提升效率。自动化工具和人工智能的应用可以显著减少对人力的依赖，从而导致部分职位的消失。尤其是在重复性高、技术含量低的岗位上，自动化的影响尤为明显。

这个例子就太多了，不一一列举了。

市场环境与外部因素

经济周期与市场波动

宏观经济的周期性波动对企业的经营状况有着深远影响。在经济衰退或市场需求下降时，企业往往会通过裁员来应对收入减少和利润率下滑的挑战。反之，在经济繁荣期，企业则可能增加招聘以满足业务扩张的需求。

最简单的例子，在互联网高速发展期，1年p6、3年p7根本不是梦，后端只要有过简单的开发经验，找工作根本不是问题。

目前中国经济增速放缓、消费升级趋势减弱、人口红利消失等因素的影响，中国互联网市场的需求增长趋于饱和或下降。再叠加就业市场饱和，企业对学历、经验提出了更多的要求。

行业竞争与市场压力

激烈的市场竞争也会促使企业通过裁员来保持竞争力。

当企业面临市场份额的争夺和利润率的压力时，降低运营成本成为必然选择。通过优化人力资源配置，企业可以在价格战或市场扩张中保持灵活性和优势。

目前用户规模停滞，智能手机普及率饱和，互联网用户规模增长趋于停滞，由增量市场变为存量市场，互联网获客成本越来越高。

政策变动与法规影响

政府政策和法规的变化也可能引发企业的裁员行为。例如，税收政策的调整、劳动法规的变化或贸易政策的波动，都会影响企业的运营成本和市场策略。在这种情况下，企业可能通过裁员来适应新的政策环境和经营压力。

就像目前互联网行业规范和监管愈加严格，更加注重合规，因此互联网行业也会收到影响。

技术发展与行业趋势

技术创新与产业升级

技术创新是推动产业升级的重要动力，也直接影响着就业结构的变化。新技术的应用往往带来生产方式的变革，导致传统岗位的减少和新兴岗位的增加。企业在追求技术领先的过程中，不可避免地会进行人力资源的调整。

其实，每一轮的市场繁荣，都是由技术创新带来的，例如3G时代叠加iPhone这样的智能手机，才打开了移动互联网快速发展的时期，才有了阿里 All in 无线的战略。

而现在正在快速发展的AI大模型，就是新一轮技术创新的开始，AI的可能性太大了。

行业趋势

数字化转型和远程办公的普及也在改变企业的用工模式。数字化工具的应用使得部分岗位可以通过外包或灵活用工的方式来完成，从而减少了全职员工的需求。远程办公的兴起则使企业有更多的选择来优化人力资源配置。

怎么做

通过之前的裁员历史，还有裁员背后的一些深层次原因，你应该能对裁员这件事背后的规律，有了一定的了解。

我们每个人都是时代中微不足道的一粒沙子，那么从个人角度，我们应该如何应对呢？

调整心态

年年涨薪，按时晋升机会等等这些互联网黄金时期的待遇，在当前可能不再是标配了，想要做到这一点，你需要在职场中付出比别人多几倍的努力，大家或许应该深有体会。

那么跳槽也不一定有涨薪，甚至工作时间长的人、base高的人，跳槽可能还会面临降薪。

所以一定要调整预期，如果岗位未来还有不错的发展空间，降薪也值得去。

还有就是要做好选择，不能既要（收入、光环），还要（轻松、自由）。

稳住基本盘

技术&业务能力
其实有挺多朋友加我，也不乏一些工作只有一两年的朋友，他们会感到焦虑，比如工作不好找、大厂不好进，是不是需要更换赛道。但是针对于工作年限不久的朋友，我始终给出的建议就是要先深耕技术，做好当前工作，这是作为一个技术人最基本的要求，也是立身之本。

无论市场环境如何，只要自己的技术或者业务能力在线，能够解决工作中遇到的问题，能够产生价值，那么你一定就会持续有一定竞争力。

身体

身体才是奋斗的本钱，长期加班、久坐，大家可能都会有或多或少的一些小毛病。

之所以把身体也列出来，是因为当下我真的感觉很容易精力不足，在持续大量学习的时候，很容易感到疲倦，下班之后就会什么也不想干，窝在沙发一晚上。

在你想做一件事情的时候，良好的身体状况才能保证你能够全身心的投入进去。

财富积累

良好的财富积累，既能提供经济缓冲，也可以增加自己的心里安全感。

如果想做职业转换时，有足够的储蓄也可以让你有更多的时间和资源去学习一些新技能。

提前探索

开头既然说了，国企也曾有过裁员潮，那么在互联网行业，我们大概率也很难干到退休了。

所以你需要提前探索自己可以长期耕耘的方向，并且对自己有一个清晰的自我认知。

比如经常问自己几个问题：

说在最后

好了，文章到这里就要结束了。

所以你看，由于企业战略、市场环境、技术趋势的影响，都有可能成为裁员的原因。所以我们不要认为裁员是自身能力不足，甚至影响自己的情绪。

面对裁员与互联网里不断宣扬的“35岁危机”，与其担忧焦虑，不如先调整心态，稳住自己当下的基本盘。

最重要的是提前探索，找到自己喜欢的事情，去探索自己的能力边界。

教你用 uni-app 开发 APP 上架 IOS 和 Android

介绍

本文记录了我使用uni-app开发构建并发布跨平台移动应用的全过程，旨在帮助新手开发者掌握如何使用uni-app进行APP开发并最终成功上架。通过详细讲解从注册开发者账号、项目创建、打包发布到应用商店配置的每一步骤，希望我的经验分享能为您提供实用的指导和帮助，让您在开发之旅中少走弯路，顺利实现自己的应用开发目标。

环境配置

IOS 环境配置

注册开发者账号 

如果没有开发者账号需要注册苹果开发者账号，并且加入 “iOS Developer Program”，如果是公司项目那么可以将个人账号邀请到公司的项目中。

获取开发证书和配置文件

登录Apple Developer找到创建证书入口

申请证书的流程可以参考Dcloud官方的教程，申请ios证书教程

开发证书和发布证书都申请好应该是这个样子

创建App ID

创建一个App ID。App ID是iOS应用的唯一标识符，稍后你会在uni-app项目的配置文件中使用它。

配置测试机

第一步打开开发者后台点击Devices

第二步填写UDID

第三步重新生成开发证书并且勾选新增的测试机，建议一次性将所有需要测试的手机加入将来就不用一遍遍重复生成证书了

Android 环境配置

生成证书

Android平台签名证书(.keystore)生成指南： ask.dcloud.net.cn/article/357…

uni-app 项目构建配置

基础配置

版本号versionCode 前八位代表年月日，后两位代表打包次数

APP 图标设置

APP启动界面配置

App模块配置

注意这个页面用到什么就配置什么不然会影响APP审核

App隐私弹框配置

注意根据工业和信息化部关于开展APP侵害用户权益专项整治要求应用启动运行时需弹出隐私政策协议，说明应用采集用户数据，这里将详细介绍如何配置弹出“隐私协议和政策”提示框

详细内容可参考Uni官方文档
注意！androidPrivacy.json不要添加注释，会影响隐私政策提示框的显示！！！

在app启动界面配置勾选后会在项目中自动添加androidPrivacy.json文件，可以双击打开自定义配置以下内容：

{

    "version" : "1",

    "prompt" : "template",

    "title" : "服务协议和隐私政策",

    "message" : "　　请你务必审慎阅读、充分理解“服务协议”和“隐私政策”各条款，包括但不限于：为了更好的向你提供服务，我们需要收集你的设备标识、操作日志等信息用于分析、优化应用性能。<br/>　　你可阅读<a href="https://xxx.xxx.com/userPolicy.html">《服务协议》</a>和<a href="https://xxxx.xxxx.com/privacyPolicy.html">《隐私政策》</a>了解详细信息。如果你同意，请点击下面按钮开始接受我们的服务。",

    "buttonAccept" : "同意并接受",

    "buttonRefuse" : "暂不同意",

    "hrefLoader" : "system|default",

    "backToExit" : "false",

    "second" : {

        "title" : "确认提示",

        "message" : "　　进入应用前，你需先同意<a href="https://xxx.xxxx.com/userPolicy.html">《服务协议》</a>和<a href="https://xxx.xxxx.com/userPolicy.html">《隐私政策》</a>，否则将退出应用。",

        "buttonAccept" : "同意并继续",

        "buttonRefuse" : "退出应用"

    },

    "disagreeMode" : {

        "loadNativePlugins" : false,

        "showAlways" : false

    },

    "styles" : {

        "backgroundColor" : "#fff",

        "borderRadius" : "5px",

        "title" : {

            "color" : "#fff"

        },

        "buttonAccept" : {

            "color" : "#22B07D"

        },

        "buttonRefuse" : {

            "color" : "#22B07D"

        },

        "buttonVisitor" : {

            "color" : "#22B07D"

        }

    }

}