(2024年11月24日发布，2025年12月21日修改)
情况说明
在Microsoft Edge浏览器中添加了“解压缩的扩展”后，会弹出如图所示的“关闭开发人员模式下的扩展”弹窗，弹出时间为每次打开第一个窗口的几秒钟后，会打断正在输入的文字。而“以后再说”选项也仅提供最多两周的不再弹出选项，无法彻底关闭，比较烦人。
从网络上找到的屏蔽方法为（多为Chrome的，不过现在的Edge也为Chromium内核和Chrome高度相似，所以理论上效果一样）：
使用弹窗拦截程序，如火绒的弹窗拦截工具（据评论区反馈，弹窗依然会弹出并打断，只是省去了手动关闭，效果不理想）；
打补丁，原理为反编译修改程序以跳过弹窗（自己修改比较麻烦，按版本找现成补丁比较难且不太安全，而且升级后会失效，不理想）；
安装替换为Dev版的Microsoft Edge（未测试，效果未知）；
经过思考，“以后再说”的“2周后提醒”选项应该在某一配置文件内，以特定方式存储下次弹出的时间，只要找到并将其修改为较大的时间值，理论上就约等于禁用掉了这一弹窗。
禁用方法
1、找到“用户配置路径”
在Edge地址栏中输入edge://version（about:version或chrome://version均可）找到“用户配置路径”，默认为
C:\Users\[Windows用户名]\AppData\Local\Microsoft\Edge\User Data\Default
该禁用方法仅对单个用户生效，如果Edge中有多个用户需要禁用该弹窗，则需要分别对其配置文件进行该系列修改操作。
2、确保Edge彻底关闭
一定要在彻底关闭Edge后再打开下述文件进行编辑，避免不生效或其他配置的新值被旧值覆盖而出错。而Edge默认启用了“启动增强”功能，即使窗口全部关闭进程也会在后台驻留，因此必须在任务管理器中确认没有msedge.exe进程后再进行后续操作。
3、打开Preferences文件
在记事本或其他文本/代码编辑器中，打开步骤1中“用户配置路径”文件夹下的Preferences文件（JSON格式）。可通过快捷键Win+R调出“运行”后输入
notepad [步骤1中的“用户配置路径”]\Preferences
快速打开（不区分大小写），Edge中的默认用户则可直接输入（可省去步骤1）
notepad %LocalAppData%\Microsoft\Edge\User Data\Default\Preferences
对于不会自动更新显示最新内容的编辑器来说，一定要在确保Edge彻底关闭后再打开该文件。
4、查找“dev_mode_warning_snooze_end_time”
据评论区反馈，如果未点击过“2周后提醒”选项，则配置文件中会找不到该键，需要打开Edge后完成一次点击后再从步骤2重新操作，或者（码农）可以找到extensions.ui后手动添加。
5、修改数值并保存
找到该键后修改其值（冒号后引号下数字）为 9223372036854775807 后保存即可。理论上可修改为任意小于该数字且远大于当前值的整数，保证其对应的再次弹出时间可视为不会再弹出即可。
分析过程
当想到上述找相应配置文件后，第一时间想到的就是Chromium内核默认的Preferences文件，通过查找分析与extension有关的内容后找到了
extensions.ui.dev_mode_warning_snooze_end_time
翻译为“开发者模式警告推迟结束时间”，显而易见，这就是要找的相应的配置。
分析发现，这并不是常见的UNIX时间戳，当前才仅10位（单位秒）或13位（单位毫秒）十进制，而该值为17位十进制、14位16进制，因此可以肯定的是该数据的类型为64位整数，故可修改为任意远大于当前值且小于有符号INT64的最大值9223372036854775807（即0x7FFFFFFFFFFFFFFF）或无符号UINT64的最大值18446744073709551615（即0xFFFFFFFFFFFFFFFF）。起初因为无法确定其时间类型及其内部使用的是有符号整数还是无符号整数，保险起见修改为了有符号INT64的最大值后发现确实生效了，就没再继续管它，后来打算写这篇专栏时才又继续分析了下，如下：
因为之前使用过Windows获取时间的API，在排除了UNIX时间戳后首先想到的便是它，于是简单写了个测试程序，关键代码如下：
union { FILETIME ft; UINT64 u64; } time;
GetSystemTimeAsFileTime(&time.ft);
printf("%llu\t%016llX\n", time.u64, time.u64);
获得的十进制输出值和配置文件中的当前值前好多位都是一致的，所以说它是Windows FILETIME时间类型的对应数值？并不完全是，因为我发现配置文件中的值比测试程序输出值的十进制少了一位，所以它是Windows FILETIME对应数值÷10？验证如下：
首先，同上述禁用方法，但将其修改为一个较小的值如‘0’，然后打开Edge后弹窗如期出现，点击“2周后提醒”，于是配置文件中的值便被如期修改。复制并使用以下代码验证：
SYSTEMTIME sysTime;
union { FILETIME ft; UINT64 u64; } time;
time.u64 = 10 * 13378129017868001; // 复制的值
FileTimeToSystemTime(&time.ft, &sysTime);
printf("%u/%02u/%02u %02u:%02u:%02u\n", sysTime.wYear, sysTime.wMonth, sysTime.wDay, sysTime.wHour, sysTime.wMinute, sysTime.wSecond);
输出值为：2024/12/08 10:56:57，刚好是据点击时间两周后的UTC时间，所以配置文件中该值的类型为Windows FILETIME时间类型的对应数值÷10，即自UTC 1601年1月1日以来的微秒间隔数。
Windows FILETIME类型实测应为有符号64位整数，支持的最大值为0x7FFFFFFFFFFFFFFF即9223372036854775807，对应时间为UTC 30828年09月14日 02:48:05，但由于和该配置文件中的时间类型不是直接对应的关系，因此无法推出该时间配置支持的最大值。经测试，修改为无符号UINT64的最大值，或者有符号INT64的最大值+1后，均会出现该弹窗，因此可以确定其内部使用的是有符号的INT64，对应的最大值同上，但由于其对应的Windows FILETIME值（上述值×10后）已超出UINT64的范围，无法用上述第二段代码计算其对应哪一天了，估计Edge内部也无法达到这一天，可以认为其被永久禁用了（即使是FILETIME对应的最大时间也已遥不可及）。
附：UNIX时间戳表示自UTC 1970年1月1日开始所经过的秒数；Windows FILETIME类型的对应数值表示自UTC 1601年1月1日以来的 100 纳秒间隔数（Windows提供的文档中并不建议将FILETIME直接作为或转化为数值使用，而是推荐通过函数进行数值转换为ULARGE_INTEGER类型即无符号UINT64，但实测无区别且经测试当二进制最高位为1时计算后的时间值均为31/00/00 00:00:00）。
https://baike.baidu.com/item/unix时间戳/2078227
https://learn.microsoft.com/windows/win32/api/minwinbase/ns-minwinbase-filetime
