目次
1.  组件初始化 _construct
2.  加载配置文件 load
3.  获取配置项item,slash_item
4.  获取站点site_url, base_url,system_url
5.  获取URI String: _uri_string
6.  设置配置项 set_item  _assign_to_config
ホームページ php教程 php手册 CI框架源码阅读笔记7 配置管理组件 Config.php

CI框架源码阅读笔记7 配置管理组件 Config.php

Jun 06, 2016 pm 07:36 PM
フレーム ソースコード ノート 管理 コンポーネント 構成 読む

一个灵活可控的应用程序中,必然会存在大量的可控参数(我们称为 配置 ),例如在CI的主 配置 文件中(这里指Application/Config/Config.php文件),有如下多项 配置 : $config ['base_url'] = 'http://test.xq.com' ; $config ['index_page'] = '' ; $conf

 一个灵活可控的应用程序中,必然会存在大量的可控参数(我们称为配置),例如在CI的主配置文件中(这里指Application/Config/Config.php文件),有如下多项配置

<span>$config</span>['base_url']   = 'http://test.xq.com'<span>;
</span><span>$config</span>['index_page'] = ''<span>;
</span><span>$config</span>['uri_protocol']     = 'AUTO'<span>;
</span><span>$config</span>['url_suffix'] = '.html'<span>;
</span><span>$config</span>['language']  = 'english'<span>;
</span><span>$config</span>['charset'] = 'UTF-8'<span>;
</span><span>$config</span>['enable_hooks'] = <span>FALSE</span><span>;
…………………………</span>
ログイン後にコピー

不仅如此,CI还允许你将配置参数放到主配置文件之外。例如,你可以定义自己的配置文件为Config_app.php, 然后在你的应用程序控制器中这样加载你的配置文件:

<span>$this</span>->config->load('config_app');
ログイン後にコピー

如此纷繁多样的配置项和配置文件,CI是如何进行管理的?这便是我们今天要跟踪的内容:CI的配置管理组件-Config.php.

先看该组件的类图:

CI框架源码阅读笔记7 配置管理组件 Config.php

其中:

_config_paths:要搜索的配置文件的路径,这里指APPPATH目录,你的配置文件也应该位于APPPATH下。

Config: 这个数组用于存放所有的配置项的item

Is_loaded: 存放所有的已经加载的配置文件列表。

_construct: 组件的构造函数,主要是配置base_url

_assign_to_config: 允许index.php中的配置项覆盖主配置文件中的设置

_uri_string,site_url,base_url,system_url: URI, 项目路径等相关处理。

load: 加载配置文件。

item:获取配置

slash_item:同item,不同的是,在最后加了”\”分隔符,一般只有site_url,base_url等会需要slash_item

下面我们去剖析各个方法的具体实现:

1.  组件初始化 _construct

之前我们在分析Common.php全局函数的时候提到过,在Config组件实例化之前,所有的组配置文件的获取都是由get_config()函数来代理的。在Config组件实例化时,要将所有的配置存放到自己的私有变量$config中,便于之后的访问和处理:

$this->config =& get_config();
ログイン後にコピー

由于我们应用程序很多时候需要获取base_url的值,而这个值并不是必填项(config中base_url可以设置为空),但我们又不希望获取到的base_url的值为空。因此,CI在Config组件初始化的时候,对base_url做了一定的处理。这主要出现在Config.php中base_url设置为空的情况:

(1).    如果设置了$_SERVER[‘HTTP_HOST’],则base_url被设置为Protocal(http或者https) + $_SERVER['HTTP_HOST'] + SCIRPT_PATH的形式:

$base_url = isset($_SERVER['HTTPS']) && strtolower($_SERVER['HTTPS']) !== 'off' ? 'https' : 'http';
$base_url .= '://'. $_SERVER['HTTP_HOST'];
$base_url .= str_replace(basename($_SERVER['SCRIPT_NAME']), '', $_SERVER['SCRIPT_NAME']);
ログイン後にコピー

(2).    否者,直接被设置为http://localhost/:

$base_url = 'http://localhost/';
ログイン後にコピー

(3).    同时将base_url配置项映射到配置数组中,方便之后的访问(set_item方法我们稍后会将,这里只需要知道,它是添加到配置项且会覆盖旧值):

$this->set_item('base_url', $base_url);
ログイン後にコピー

之后我们会看到,base_url这个配置项对于很多组件都是必须的,因此,CI花费一定的精力来保证base_url的正确性,也是可以理解的。

2.  加载配置文件 load

这是Config组件中较核心的方法之一,该函数的签名:

<span>function</span> load(<span>$file</span> = '', <span>$use_divs</span> = <span>FALSE</span>, <span>$fail_gracefully</span> = <span>FALSE</span>)
ログイン後にコピー

所有的参数都是可选参数。

我们这里简单解释一下各形参的含义:

  $file 需要加载的配置文件,可以包含后缀名也不可以不包含,如果未指定该参数,则默认加载Config.php文件

  $user_divs: 是否为加载的配置文件使用独立的div,这么说可能还是不明白,试想,如果你定义了自己的配置文件,而你的配置文件中的配置项可能与Config.php文件中的配置项冲突,通过指定$div为true可以防止配置项的覆盖。

  $fail_gracefully: 要load的配置文件不存在时的处理。Gracefully意为优雅的,如果该参数设置为true,则在文件不存在时只会返回false,而不会显示错误。

下面看该方法的具体实现:

(1). 配置文件名预处理:

<span>$file</span> = (<span>$file</span> == '') ? 'config' : <span>str_replace</span>('.php', '', <span>$file</span>);
ログイン後にコピー

这个$file最后只包含文件名,而不包含扩展名。如果该参数为空,则默认加载Config.php配置文件。这同时也说明,我们加载自己的配置文件时:

$this->config->load("");

$this->config->load("config")效果是一样的,而:

$this->config->load("config_app")

$this->config->load("config_app.php")的效果也是一样的。

如果启用了$use_divs,这个$file会作为config的主键。

(2).    查找和加载配置文件。

在跟踪实现之前,先解释几个查找和加载过程中比较重要的参数:

  1. $found  这个参数实际上是个flag,用于标识配置文件是否查找到,一旦查找到配置文件,则停止任何搜索。
  2. $loaded  同$found参数类似,这个$loaded也是一个flag,用于标识请求的配置文件是否被加载。一般情况下,被加载的配置文件会被CI_Config:: is_loaded变量追踪
  3. $_config_path  要查找的配置路径,这个变量由于是写死在Config组件中的,且没有提供添加或者更改的接口。因此我们可以认为_config_path就是APPPATH.也就是,配置文件的load一定是在APPPATH目录下查找的。
  4. $check_locations  这个参数是要查找的位置(具体文件)。同样,如果定了ENVIRONMENT且存在相应ENVIRONMENT下的配置文件,优先加载该文件。

(3).具体的查找过程是一个双重的foreach循环:

/*  对于config_paths中的路径循环查找 */
foreach ($this->_config_paths as $path)
{	
  /* 对每个location查找,也就是分别对ENVIRONMENT/config/ 和 config/ 目录查找  */
  foreach ($check_locations as $location)
  {
	/* 实际的<strong>配置</strong>文件名 */
	$file_path = $path.'config/'.$location.'.php';
	<br>	/* 如果已经加载,则跳至最外层循环,事实上,由于_config_paths的设定,会跳出整个循环 */
	if (in_array($file_path, $this->is_loaded, TRUE))
	{
	  $loaded = TRUE;
	  continue 2;
	}
		
	/* 若文件存在,跳出当前循环 */
	if (file_exists($file_path))
	{
	  $found = TRUE;
	  break;
	}
  }
  /* 如果没有找到<strong>配置</strong>文件,继续下一次循环。同样,由于_config_path的设定,会跳出整个循环 */
  if ($found === FALSE)
  {
	continue;
  }
}
ログイン後にコピー

(4).引入配置文件

到这里,如果配置文件不存在,则$found和$loaded都为false,CI会根据fail_gracefully参数决定文件不存在的处理方式;如果文件存在,则需要对配置文件的格式检查:

/* 引入<strong>配置</strong>文件 */
include($file_path);

/* <strong>配置</strong>文件的格式检查,这同时也说明,<strong>配置</strong>文件中最起码应该包含$config数组 */
if ( ! isset($config) OR ! is_array($config))
{
  if ($fail_gracefully === TRUE)
  {
	return FALSE;
  }
  show_error('Your '.$file_path.' file does not appear to contain a valid configuration array.');
}
ログイン後にコピー

(5).对use_divs参数的处理

前面说过,use_secitons参数如果为true,则CI_Config会对该配置文件启用独立的key存储。例如,我们在controller中这样加载配置文件:

<span>$this</span>->config->load("config_app",<span>true</span>);
ログイン後にコピー

则config数组是这样的格式:

[config] => <span>Array</span><span>
(
    [base_url] </span>=> http:<span>//</span><span>test.xq.com</span>
    [index_page] =><span>
    [uri_protocol] </span>=><span> AUTO
    [url_suffix] </span>=> .<span>html
    [proxy_ips] </span>=><span>
    [web_akey] </span>=><span> yyyyyyyyyyyy
    [config_app] </span>=> <span>Array</span><span>
        (
            [web_akey] </span>=><span> xxxxxxx
            [web_skey] </span>=><span> xxxxxxxxxxxxxxxxxxx
            [web_callback_url] </span>=> http:<span>//</span><span>test.xq.com/</span>
            [sess_pre] =><span> WEB_APP
            [cart_min] </span>=> 1<span>
            [cart_max] </span>=> 999<span>
        )
)</span>
ログイン後にコピー

相反,如果我们不指定use_divs,则数组是这样存储的:

[config] => <span>Array</span><span>
(
    [base_url] </span>=> http:<span>//</span><span>test.xq.com</span>
    [index_page] =><span>
    [uri_protocol] </span>=><span> AUTO
    [url_suffix] </span>=> .<span>html
    [web_akey] </span>=><span> xxxxxxx
    [web_skey] </span>=><span> xxxxxxxxxxxxxxxxxxx
    [web_callback_url] </span>=> http:<span>//</span><span>test.xq.com/</span>
    [sess_pre] =><span> WEB_APP
    [cart_min] </span>=> 1<span>
    [cart_max] </span>=> 999<span>
)</span>
ログイン後にコピー

这也意味着,在不启用user_secitons的情况下,如果你的配置文件中有与主配置文件Config.php相同的键,则会覆盖主配置文件中的项:

/* 启用单独的key存放加载的config */
if ($use_divs === TRUE)
{
  if (isset($this->config[$file]))
  {
	$this->config[$file] = array_merge($this->config[$file], $config);
  }
  else
  {
	$this->config[$file] = $config;
  }
}
else
{
  /* 执行merge,更改CI_Config::config */
  $this->config = array_merge($this->config, $config);
}
ログイン後にコピー

(6).错误处理

双层循环完成后,如果loaded为false,也就是未成功加载任何配置,则根据fail_gracefully做相应的错误处理:

/* 未成功加载任何<strong>配置</strong> */
if ($loaded === FALSE)
{
  if ($fail_gracefully === TRUE)
  {
	return FALSE;
  }
  show_error('The configuration file '.$file.'.php does not exist.');
}
ログイン後にコピー

3.  获取配置项item,slash_item

item方法用于在配置中获取特定的配置项,改方法的签名:

<span>function</span> item(<span>$item</span>, <span>$index</span> = '')
ログイン後にコピー

注意,如果你在load配置文件的时候启用了use-divs,则在使用item()获取配置项的时候需要指定第二个参数,也就是加载的配置文件的文件名(不包含后缀)。为了更清楚这一点,我们假设现在Config/目录下有配个配置文件:config.php和config_app.php,这两个配置文件中含有一个相同的键web_akey, 在config.php中,该配置为:

<span>$config</span>['web_akey']  = 'yyyyyyyyyyyy';
ログイン後にコピー

而config_app.php中,该配置为:

<span>$config</span>['web_akey'] = 'xxxxxxx';
ログイン後にコピー

现在,通过use-divs的方法加载config_app配置文件(config.php会在Config组件初始化的时候被加载):

$this->config->load("config_app",true);
ログイン後にコピー

然后在控制器中获取web_akey配置项:

echo "config_app:web_akey => ",$this->config->item("web_akey","config_app"),"<br>";
echo "config    :web_akey => ",$this->config->item("web_akey");
ログイン後にコピー

实际的获取结果:

config_app:web_akey =><span> xxxxxxx
config </span>:web_akey => yyyyyyyyyyyy
ログイン後にコピー

了解原理之后,该方法的实现就比较简单了:

function item($item, $index = '')
{	
  /* 没有设置use_divs的情况,直接在config中寻找<strong>配置</strong>项 */
  if ($index == '')
  {
	if ( ! isset($this->config[$item]))
	{
	  return FALSE;
	}

	$pref = $this->config[$item];
  }
  else
  {
	if ( ! isset($this->config[$index]))
	{
	  return FALSE;
	}

	if ( ! isset($this->config[$index][$item]))
	{
	  return FALSE;
	}
	$pref = $this->config[$index][$item];
  }
  /* 统一的return出口 */
  return $pref;
}
ログイン後にコピー

slash_item实际上与item()方法类似,但他不会去用户的配置中寻找,并且,他返回的是主配置文件中的配置项,并在配置项最后添加反斜杠.这个方法,通常用于base_url和index_page这两个配置项的处理:

CI框架源码阅读笔记7 配置管理组件 Config.php

该方法的实现源码:

function slash_item($item)
{	
  /* 不存在<strong>配置</strong>项 */
  if ( ! isset($this->config[$item]))
  {
	return FALSE;
  }
  /* <strong>配置</strong>项为空 */
  if( trim($this->config[$item]) == '')
  {
	return '';
  }
	
  /* 去除最后的多余的"/",并在结尾添加一个"/" */
  return rtrim($this->config[$item], '/').'/';
}
ログイン後にコピー

4.  获取站点site_url, base_url,system_url

这里先澄清这几个含义的区别:

echo "site_url  : ",$this->config->site_url("index/rain"),"";
echo "base_url  : ",$this->config->base_url("index/rain"),"<br>";
echo "system_url: ",$this->config->system_url();
ログイン後にコピー

的结果分别是:

<span>site_url : http://test.xq.com/index/rain.html
base_url : http://test.xq.com/index/rain
system_url: http://test.xq.com/system/</span>
ログイン後にコピー

可以看出,site_url是添加了suffix(在Config/config.php中配置)后的url地址(呵呵,如果你的uri中有query string,则Ci总是在最后添加suffix:http://test.xq.com/index/rain?w=ss.html  是不是很奇怪.)

base_url则是没有添加suffix的url地址。

而system_url这个东西很奇怪,是获取系统的url路径。但实际上,由于system路径并没有直接执行的脚本,所以这个方法的实际用途是什么,暂时不知。有知道的童鞋麻烦告知。

具体的方法实现,这里不赘述了。直接贴出源码:

function site_url($uri = '')
{
	/* 没有设置uri,使用base_url + index_page */
	if ($uri == '')
	{
		return $this->slash_item('base_url').$this->item('index_page');
	}
	
	/* enable_query_strings未启用,可以添加suffix后缀 */
	if ($this->item('enable_query_strings') == FALSE)
	{
		$suffix = ($this->item('url_suffix') == FALSE) ? '' : $this->item('url_suffix');
		return $this->slash_item('base_url').$this->slash_item('index_page').$this->_uri_string($uri).$suffix;
	}
	/* 否者不添加suffix后缀 */
	else
	{
		return $this->slash_item('base_url').$this->item('index_page').'?'.$this->_uri_string($uri);
	}
}

/* 获取base_url,注意与site_url的区别 */
function base_url($uri = '')
{
	return $this->slash_item('base_url').ltrim($this->_uri_string($uri), '/');
}

/* 获取system url */
function system_url()
{
       /* 获取系统目录.   BASEPATH:/search/xx/phpCode/CI/system/ */
    $x = explode("/", preg_replace("|/*(.+?)/*$|", "\\1", BASEPATH));
    return $this->slash_item('base_url').end($x).'/';
}
ログイン後にコピー

5.  获取URI String: _uri_string

site_url和base_url都调用了_uri_string。这个函数是做什么用的呢?

按理来说, _uri_string的功能应该由URI组件来完成,这里却放在了Config组件中,似乎有些不妥(实际上,_uri_string是为base_url和site_url专属服务的)。

对于这样的uri:

<span>array(
    'p1' </span>=> 'param1',<span>
    'p2' </span>=<span>> 'param2'
)</span>
ログイン後にコピー

如果enable_query_string为false,则_uri_string处理过后是这样的形式:

param1/param2
ログイン後にコピー

而enable_query_string为true,则处理后的形式是这样的:

p1=param1&p2=param2
ログイン後にコピー

这是我们常见(虽然很难看且SEO不好)的形式。改方法的实现源码:

protected function _uri_string($uri)
{	
	/* enable_query_strings 为false,直接implode */
	if ($this->item('enable_query_strings') == FALSE)
	{
		if (is_array($uri))
		{
			$uri = implode('/', $uri);
		}
		$uri = trim($uri, '/');
	}
	/* 否者,拼接成类似param1=param1&param2=param2的形式 */
	else
	{
		if (is_array($uri))
		{
			$i = 0;
			$str = '';
			foreach ($uri as $key => $val)
			{	
				/* 第一个参数前面不需要加& */
				$prefix = ($i == 0) ? '' : '&';
				$str .= $prefix.$key.'='.$val;
				$i++;
			}
			$uri = $str;
		}
	}
    return $uri;
}
ログイン後にコピー

6.  设置配置项 set_item  _assign_to_config

与item()相反,set_item用于设置配置项。如果配置项已经存在,则会被覆盖:

$this->config[$item] = $value;
ログイン後にコピー

_assign_to_config同set_item,该方法提供了数组的设置方式(调用set_item。我们之前在解释CodeIgniter.php文件的时候提到过:改方法允许在index.php中设置独立的配置项,且index.php中的配置具有更高的优先权(会覆盖主配置文件中的配置):

function _assign_to_config($items = array())
{
	if (is_array($items))
	{
		foreach ($items as $key => $val)
		{
			$this->set_item($key, $val);
		}
	}
}
ログイン後にコピー

到这里,Config组件的基本解析就算是完成了,我们再次回顾下该组件的基本功能:

  1. set_item和item是Config组件的基本对外接口。也就是常见的setter 和getter,_assign_to_config算是批量的setter,slash_item则是特殊处理的getter
  2. load方法是加载配置文件,如果你自定义了自己的配置文件,需要先load使得你的配置纳入CI_Config的管理之下。
  3. system_url,base_url,site_url,用于获取特定的配置项。
  4. _uri_string是CI_Config中唯一一个Protected的方法。这个方法主要是处理uri,提供给site_url和base_url使用

最后感慨一下,一个好的Config组件,会省不少事啊。

このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。

ホットAIツール

Undresser.AI Undress

Undresser.AI Undress

リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover

AI Clothes Remover

写真から衣服を削除するオンライン AI ツール。

Undress AI Tool

Undress AI Tool

脱衣画像を無料で

Clothoff.io

Clothoff.io

AI衣類リムーバー

AI Hentai Generator

AI Hentai Generator

AIヘンタイを無料で生成します。

ホットツール

メモ帳++7.3.1

メモ帳++7.3.1

使いやすく無料のコードエディター

SublimeText3 中国語版

SublimeText3 中国語版

中国語版、とても使いやすい

ゼンドスタジオ 13.0.1

ゼンドスタジオ 13.0.1

強力な PHP 統合開発環境

ドリームウィーバー CS6

ドリームウィーバー CS6

ビジュアル Web 開発ツール

SublimeText3 Mac版

SublimeText3 Mac版

神レベルのコード編集ソフト(SublimeText3)

Java フレームワークの商用サポートの費用対効果を評価する方法 Java フレームワークの商用サポートの費用対効果を評価する方法 Jun 05, 2024 pm 05:25 PM

Java フレームワークの商用サポートのコスト/パフォーマンスを評価するには、次の手順が必要です。 必要な保証レベルとサービス レベル アグリーメント (SLA) 保証を決定します。研究サポートチームの経験と専門知識。アップグレード、トラブルシューティング、パフォーマンスの最適化などの追加サービスを検討してください。ビジネス サポートのコストと、リスクの軽減と効率の向上を比較検討します。

PHP フレームワークの軽量オプションはアプリケーションのパフォーマンスにどのような影響を与えますか? PHP フレームワークの軽量オプションはアプリケーションのパフォーマンスにどのような影響を与えますか? Jun 06, 2024 am 10:53 AM

軽量の PHP フレームワークは、サイズが小さくリソース消費が少ないため、アプリケーションのパフォーマンスが向上します。その特徴には、小型、高速起動、低メモリ使用量、改善された応答速度とスループット、および削減されたリソース消費が含まれます。 実際のケース: SlimFramework は、わずか 500 KB、高い応答性と高スループットの REST API を作成します。

Golang フレームワークのドキュメントのベスト プラクティス Golang フレームワークのドキュメントのベスト プラクティス Jun 04, 2024 pm 05:00 PM

明確で包括的なドキュメントを作成することは、Golang フレームワークにとって非常に重要です。ベスト プラクティスには、Google の Go コーディング スタイル ガイドなど、確立されたドキュメント スタイルに従うことが含まれます。見出し、小見出し、リストなどの明確な組織構造を使用し、ナビゲーションを提供します。スタート ガイド、API リファレンス、概念など、包括的で正確な情報を提供します。コード例を使用して、概念と使用法を説明します。ドキュメントを常に最新の状態に保ち、変更を追跡し、新機能を文書化します。 GitHub の問題やフォーラムなどのサポートとコミュニティ リソースを提供します。 API ドキュメントなどの実践的なサンプルを作成します。

PHP フレームワークの学習曲線は他の言語フレームワークと比較してどうですか? PHP フレームワークの学習曲線は他の言語フレームワークと比較してどうですか? Jun 06, 2024 pm 12:41 PM

PHP フレームワークの学習曲線は、言語熟練度、フレームワークの複雑さ、ドキュメントの品質、コミュニティのサポートによって異なります。 PHP フレームワークの学習曲線は、Python フレームワークと比較すると高く、Ruby フレームワークと比較すると低くなります。 Java フレームワークと比較すると、PHP フレームワークの学習曲線は中程度ですが、開始までの時間は短くなります。

さまざまなアプリケーションシナリオに最適な Golang フレームワークを選択する方法 さまざまなアプリケーションシナリオに最適な Golang フレームワークを選択する方法 Jun 05, 2024 pm 04:05 PM

アプリケーションのシナリオに基づいて最適な Go フレームワークを選択します。アプリケーションの種類、言語機能、パフォーマンス要件、エコシステムを考慮します。一般的な Go フレームワーク: Jin (Web アプリケーション)、Echo (Web サービス)、Fiber (高スループット)、gorm (ORM)、fasthttp (速度)。実際のケース: REST API (Fiber) の構築とデータベース (gorm) との対話。フレームワークを選択します。主要なパフォーマンスには fasthttp、柔軟な Web アプリケーションには Jin/Echo、データベース インタラクションには gorm を選択してください。

golang フレームワーク開発の実践的な詳細な説明: 質疑応答 golang フレームワーク開発の実践的な詳細な説明: 質疑応答 Jun 06, 2024 am 10:57 AM

Go フレームワーク開発における一般的な課題とその解決策は次のとおりです。 エラー処理: 管理にはエラー パッケージを使用し、エラーを一元的に処理するにはミドルウェアを使用します。認証と認可: サードパーティのライブラリを統合し、資格情報を確認するためのカスタム ミドルウェアを作成します。同時処理: ゴルーチン、ミューテックス、チャネルを使用してリソース アクセスを制御します。単体テスト: 分離のために getest パッケージ、モック、スタブを使用し、十分性を確保するためにコード カバレッジ ツールを使用します。デプロイメントとモニタリング: Docker コンテナを使用してデプロイメントをパッケージ化し、データのバックアップをセットアップし、ログ記録およびモニタリング ツールでパフォーマンスとエラーを追跡します。

Golang フレームワークのパフォーマンス比較: 賢明な選択を行うための指標 Golang フレームワークのパフォーマンス比較: 賢明な選択を行うための指標 Jun 05, 2024 pm 10:02 PM

Go フレームワークを選択する場合、主要業績評価指標 (KPI) には、応答時間、スループット、同時実行性、リソース使用量が含まれます。フレームワークの KPI をベンチマークして比較することで、開発者は、予想される負荷、パフォーマンスが重要なセクション、リソースの制約を考慮しながら、アプリケーションのニーズに基づいて情報に基づいた選択を行うことができます。

Golang フレームワークの学習プロセスでよくある誤解は何ですか? Golang フレームワークの学習プロセスでよくある誤解は何ですか? Jun 05, 2024 pm 09:59 PM

Go フレームワークの学習には、フレームワークへの過度の依存と柔軟性の制限という 5 つの誤解があります。フレームワークの規則に従わない場合、コードの保守が困難になります。古いライブラリを使用すると、セキュリティと互換性の問題が発生する可能性があります。パッケージを過度に使用すると、コード構造が難読化されます。エラー処理を無視すると、予期しない動作やクラッシュが発生します。

See all articles